Exit Zen
132
../../protocols/ipv6.rst:422
English
To solve these problems, IPv6 includes a packet fragmentation and reassembly mechanism. In IPv4, fragmentation was performed by both the hosts and the intermediate routers. However, experience with IPv4 has shown that fragmenting packets in routers was costly [KM1995]_. For this reason, the developers of IPv6 have decided that routers would not fragment packets anymore. In IPv6, fragmentation is only performed by the source host. If a source has to send a packet which is larger than the MTU of the outgoing interface, the packet needs to be fragmented before being transmitted. In IPv6, each packet fragment is an IPv6 packet that includes the `Fragmentation` header. This header is included by the source in each packet fragment. The receiver uses them to reassemble the received fragments.
0/7970 · 797
133
../../protocols/ipv6.rst:427
English
IPv6 fragmentation header
0/250 · 25
134
../../protocols/ipv6.rst:429
English
If a router receives a packet that is too long to be forwarded, the packet is dropped and the router returns an ICMPv6 message to inform the sender of the problem. The sender can then either fragment the packet or perform Path MTU discovery. In IPv6, packet fragmentation is performed only by the source by using IPv6 options.
0/3260 · 326
135
../../protocols/ipv6.rst:433
English
In IPv6, fragmentation is performed exclusively by the source host and relies on the fragmentation header. This 64 bits header is composed of six fields :
0/1540 · 154
136
../../protocols/ipv6.rst:435
English
a `Next Header` field that indicates the type of the header that follows the fragmentation header
0/970 · 97
137
../../protocols/ipv6.rst:436
English
two `Reserved` fields set to `0`.
0/330 · 33
138
../../protocols/ipv6.rst:437
English
the `Fragment Offset` is a 13-bit unsigned integer that contains the offset, in 8 bytes units, of the data following this header, relative to the start of the original packet.
0/1750 · 175
139
../../protocols/ipv6.rst:438
English
the `More` flag, which is set to `0` in the last fragment of a packet and to `1` in all other fragments.
0/1040 · 104
140
../../protocols/ipv6.rst:439
English
the 32-bit `Identification` field indicates to which original packet a fragment belongs. When a host sends fragmented packets, it should ensure that it does not reuse the same `identification` field for packets sent to the same destination during a period of `MSL` seconds. This is easier with the 32 bits `identification` used in the IPv6 fragmentation header, than with the 16 bits `identification` field of the IPv4 header.
0/4260 · 426
141
../../protocols/ipv6.rst:445
English
Some IPv6 implementations send the fragments of a packet in increasing fragment offset order, starting from the first fragment. Others send the fragments in reverse order, starting from the last fragment. The latter solution can be advantageous for the host that needs to reassemble the fragments, as it can easily allocate the buffer required to reassemble all fragments of the packet upon reception of the last fragment. When a host receives the first fragment of an IPv6 packet, it cannot know a priori the length of the entire IPv6 packet.
0/5430 · 543
142
../../protocols/ipv6.rst:447
English
The figure below provides an example of a fragmented IPv6 packet containing a UDP segment. The `Next Header` type reserved for the IPv6 fragmentation option is 44.
0/1630 · 163
143
../../protocols/ipv6.rst:453
English
IPv6 fragmentation example
0/260 · 26
144
../../protocols/ipv6.rst:455
English
The following pseudo-code details the IPv6 fragmentation, assuming that the packet does not contain options.
0/1080 · 108
145
../../protocols/ipv6.rst:490
English
In the above pseudocode, we maintain a single 32 bits counter that is incremented for each packet that needs to be fragmented. Other implementations to compute the packet identification are possible. :rfc:`2460` only requires that two fragmented packets that are sent within the MSL between the same pair of hosts have different identifications.
0/3450 · 345
146
../../protocols/ipv6.rst:492
English
The fragments of an IPv6 packet may arrive at the destination in any order, as each fragment is forwarded independently in the network and may follow different paths. Furthermore, some fragments may be lost and never reach the destination.
0/2390 · 239
147
../../protocols/ipv6.rst:494
English
The reassembly algorithm used by the destination host is roughly as follows. First, the destination can verify whether a received IPv6 packet is a fragment or not by checking whether it contains a fragment header. If so, all fragments with the some identification must be reassembled together. The reassembly algorithm relies on the `Identification` field of the received fragments to associate a fragment with the corresponding packet being reassembled. Furthermore, the `Fragment Offset` field indicates the position of the fragment payload in the original non-fragmented packet. Finally, the packet with the `M` flag reset allows the destination to determine the total length of the original non-fragmented packet.
0/7170 · 717
148
../../protocols/ipv6.rst:496
English
Note that the reassembly algorithm must deal with the unreliability of the IP network. This implies that a fragment may be duplicated or a fragment may never reach the destination. The destination can easily detect fragment duplication thanks to the `Fragment Offset`. To deal with fragment losses, the reassembly algorithm must bind the time during which the fragments of a packet are stored in its buffer while the packet is being reassembled. This can be implemented by starting a timer when the first fragment of a packet is received. If the packet has not been reassembled upon expiration of the timer, all fragments are discarded and the packet is considered to be lost.
0/6760 · 676
149
../../protocols/ipv6.rst:499
English
Header compression on low bandwidth links
0/410 · 41
150
../../protocols/ipv6.rst:501
English
Given the size of the IPv6 header, it can cause huge overhead on low bandwidth links, especially when small packets are exchanged such as for Voice over IP applications. In such environments, several techniques can be used to reduce the overhead. A first solution is to use data compression in the datalink layer to compress all the information exchanged [Thomborson1992]_. These techniques are similar to the data compression algorithms used in tools such as :manpage:`compress(1)` or :manpage:`gzip(1)` :rfc:`1951`. They compress streams of bits without taking advantage of the fact that these streams contain IP packets with a known structure. A second solution is to compress the IP and TCP header. These header compression techniques, such as the one defined in :rfc:`5795` take advantage of the redundancy found in successive packets from the same flow to significantly reduce the size of the protocol headers. Another solution is to define a compressed encoding of the IPv6 header that matches the capabilities of the underlying datalink layer :rfc:`4944`.
0/10630 · 1063
151
../../protocols/ipv6.rst:503
English
The last type of `IPv6 header extension` is the `Routing` header. The ``type 0`` routing header defined in :rfc:`2460` is an example of an IPv6 option that must be processed by some routers. This option is encoded as shown below.
0/2290 · 229