While the advantage of having virtually unlimited IP addresses for things is a significant milestone, placing IPv6 on an 802.15.4 link poses some challenges that must be overcome to make 6LoWPAN usable. First is the fact that IPv6 has a Maximum Transmission Unit (MTU) size of 1280 bytes, while 802.15.4 has a limit of 127 bytes. The second issue is that IPv6 in general adds significant girth to an already bloated protocol. For example, in IPv6 headers are 40 bytes long.

Header compression is a means to compress and remove redundancy in the IPv6 standard header for efficiency reasons. Normally, header compression is status-based, meaning in a network with static links and stable connections, it works reasonably well. In a mesh network such as 6LoWPAN, this will not work. Packets hop between nodes and would require compression/decompression on each hop. Additionally, the routes are dynamic and allowed to change and transmissions may not be present for long duration. Therefore, 6LoWPAN adopted stateless and shared-context compression. The type of compression can be affected by whether or not certain specifications are met, such as using RFC4944 over RFC6922, as well as where the source and destination of a packet reside, shown as follows: 

The three cases of header compression for 6LoWPAN based on whether the route is within the local mesh, outside of mesh but to a known address, or outside of mesh to an unknown address. Compared to standard IPv6 with a 40-byte header, 6 LoWPAN can compress between 2 to 20 bytes.

Case one (in the preceding figure) is the best case communication between nodes in a local mesh. No data is sent outward to the WAN with this compressed header format. The second case implies data is sent outward to the WAN to a known address, and the last case is similar but to an address that is known. Even in the third case, which is the worst case, compression still accounts for a 50 percent reduction in traffic. 6LoWPAN also allows for UDP compression, which is beyond the scope of this book. 

Fragmentation is a secondary issue, due to the fact that the MTU sizes are incompatible between 802.15.4 (127 bytes) and IPv6 at 1280 bytes. The fragmentation system will divide each IPv6 frame into smaller segments. On the receiving side, the fragments will be reassembled. Fragmentation will differ depending on the type of routing elected during mesh configuration (we will discuss mesh-under and route – over routing later). The types of fragmentation and constraints are given as:

• Mesh-under routing fragmentation: Fragments will be reassembled only at the final destination. All fragments need to be accounted for during re-assembly. If any are missing, the entire packet needs retransmission. As a side note, mesh-under systems require all fragments to be transmitted immediately. This will generate a burst of traffic. 
• Route-over routing fragmentation: Fragments will be reassembled at every hop in the mesh. Each node along the route carries enough resources and information to rebuild all fragments. 

The fragmentation header includes a Datagram Size field, which specifies the total size of the unfragmented data. The Datagram Tag field identifies the set of fragments belonging to a payload, and the Datagram Offset indicates where the fragment belongs in a payload sequence. Note, the datagram offset is not used for the first fragment sent as the offset of a new fragment sequence should start at zero. 

Fragmentation is a resource-heavy task that demands processing and energy ability that can tax a battery-based sensor node. It is advisable to limit the data sizes (at an application level) and use header compression to reduce the power and resource constraints in a large mesh.