IPv6 fragmentation support for messages larger than the 1280 MTU

[SpencerMougey]

I was looking through the nRF documentation as well as some of the Thread documentation and I was unable to find a definitive answer about the IPv6 fragmentation support within the nRF52 SDK for Thread probably because the use case is a bit different than the typical short packet transfers.

I am looking to potentially send a large (say 5 - 8kB) Google Protobuf message over CoAP to a backend server at a periodic interval. I know that the Thread packet can really only support around 63 bytes of the payload, so it will need to be fragmented when sent over the 802.15.4 layer to fit into the 127 byte packet for LoWPAN. However, the end packet is still too large for an IPv6 message when re-assembled (exceeds the 1280 MTU), so it would need to be set up to be fragmented before sending it across the LoWPAN. My question is as follows:

If I were to try and send a 5kB message, would my message be rejected for being too large, would my message be trimmed down to 1280 bytes and sent, or would it be fragmented at an application level (using IPv6 fragmentation rules) and then send out each 1280 chunk? The APIs that I have found from OpenThread just show the message size being a uint16, but don't list the max size that is supported for the API.

For reference, this would be done using the 4.1.0 nRF5 SDK with Thread communicating to the standard border router of a Raspberry Pi connected to an nRF52840.

Any assistance is appreciated.

[Edvin]

According to this openthread github question, you cam set the message size to  2047 bytes.

BR,

Edvin

[SpencerMougey]

Hi Edvin,

Thanks. That gives me the max theoretical packet size. I assume based on the 2nd to last comment that fragmentation of the full IPv6 packet is not supported, or is that something that the Nordic Thread implementation supports? I.e. If I had a 3000 byte message I wanted to send, passing it into the transmit function would throw an error since 3000 > 2047? Instead I would need to break the packet down into smaller chunks and add in my own fragmentation sequencing (say 3 packets of 1000 bytes + some special fragmentation header data)?

[Edvin]

Without having tested this, yes, your assumption sounds correct. Have you tested?