As the diagram shows, fragmentation happens along the path, as needed. It is up to the end-device to reassemble any fragments.
Notice in the drawing how the colored boxes (representing IP packets) are fragmented by the first hop router, and they remain fragmented upon leaving the second hop router. Device B is responsible to reassemble the fragment into the IP packets before passing the reassembled packets to the upper-layer protocols.
Note:
This is only for IPv4. IPv6 requires the sending host to pre-fragment any IPv6 packets before sending them since the intermediate devices will not fragment the IPv6 packets.
Often, IP packets will need to be fragmented before encapsulation by GRE. The tunnel interface will have a smaller MTU than the physical router interface (physical interface MTU - GRE packet overhead). The tunnel interface is treated as a real interface, and the IP packets entering the tunnel will need to be fragmented before GRE encapsulation.
See RFC 7588, A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem:
2.2. A Widely Deployed Solution
Many vendors have implemented a configurable GRE fragmentation
solution. In its default configuration, the solution behaves as
follows:
- When the GRE ingress node receives a fragmentable packet with
length greater than the GMTU, it fragments the incoming packet and
encapsulates each fragment within a complete GRE header and GRE
delivery header. Fragmentation logic is as specified by the
payload protocol.
- When the GRE ingress node receives a non-fragmentable packet with
length greater than the GMTU, it discards the packet and sends an
ICMP PTB message to the packet's source.
- When the GRE egress node receives a GRE delivery packet fragment,
it silently discards the fragment without attempting to reassemble
the GRE delivery packet to which the fragment belongs.
In non-default configurations, the GRE ingress node can execute any
of the procedures defined in RFC 4459.
The solution described above is widely deployed on the Internet in
its default configuration. However, the default configuration is not
always appropriate for GRE tunnels that carry IPv6.
IPv6 requires that every link in the Internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
Therefore, the default configuration is appropriate for tunnels
that carry IPv6 only if the network is engineered so that the GMTU
is guaranteed to be 1280 bytes or greater. In all other scenarios,
a non-default configuration is required.
In the non-default configuration, when the GRE ingress router
receives a packet lager than the GMTU, the GRE ingress router
encapsulates the entire packet in a single GRE and delivery header.
It then fragments the delivery header and sends the resulting
fragments to the GRE egress node, where they are reassembled.
And:
3.3.1.1. IPv4 Payloads
By default, if the payload is fragmentable, the GRE ingress node
fragments the incoming packet and encapsulates each fragment within a
complete GRE header and GRE delivery header. Therefore, the GRE
egress node receives several complete, non-fragmented delivery
packets. Each delivery packet contains a fragment of the GRE
payload. The GRE egress node forwards the payload fragments to their
ultimate destination where they are reassembled.
Also by default, if the payload is not fragmentable, the GRE
ingress node discards the packet and sends an ICMPv4 Destination
Unreachable message to the packet's source. The ICMPv4 Destination
Unreachable message code equals 4 (fragmentation needed and DF
set). The ICMPv4 Destination Unreachable message also contains a
next-hop MTU (as specified by [RFC1191]), and the next-hop MTU is
equal to the GMTU associated with the tunnel.
The GRE ingress node supports a non-default configuration option
that invokes an alternative behavior. If that option is
configured, the GRE ingress node fragments the delivery packet.
See Section 3.3.2 for details.
RFC 791, INTERNET PROTOCOL, has a complete discussion on fragmentation, including examples:
Example 2:
In this example, we show first a moderate size internet datagram
(452 data octets), then two internet fragments that might result
from the fragmentation of this datagram if the maximum sized
transmission allowed were 280 octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 6.
Now the first fragment that results from splitting the datagram
after 256 data octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 7.
And the second fragment.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 8.
Best Answer
The IPv4
DF
flag means that an intermediate host (router) cannot fragment the packet if necessary, and it would then need to drop the packet and can send an ICMP message stating that.RFC 791, Internet Protocol says:
IPv6 does not have the concept of intermediate host fragmentation, so the flag does not exist in the IPv6 header.