The IP fragmentation and reassembly is described by the RFCs. You must fragment on 64-bit boundaries. There are RFCs dealing with this, and other sites which will describe the fragmentation and reassembly process in depth; you can do a search to find them
Start with RFC 791, INTERNET PROTOCOL:
To fragment a long internet datagram, an internet protocol module
(for example, in a gateway), creates two new internet datagrams and
copies the contents of the internet header fields from the long
datagram into both new internet headers. The data of the long
datagram is divided into two portions on a 8 octet (64 bit) boundary
(the second portion might not be an integral multiple of 8 octets,
but the first must be). Call the number of 8 octet blocks in the
first portion NFB (for Number of Fragment Blocks). The first
portion of the data is placed in the first new internet datagram,
and the total length field is set to the length of the first
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 TTL of a packet is decremented as the packet is processed by the IP process upon reception in the router. The packet gets fragmented, if necessary to traverse the exit network (assuming the packet is not marked DF), by the IP process at the exit interface of the router. The TTL of the resulting packet fragments will be the same as if the packet were not fragmented.
RFC 791, Internet Protocol has a full description of fragmentation, and it explains that the header fields are copied from the original packet to the packet fragments: