The reassembly buffer only needs (and stores) the headers *before* the
fragment header (called per-fragment headers in RFC 8200, section 4.5).
Currently, when a subsequent IPv6 fragment is received before the first
fragment the fragment header is however not removed. With this fix it
does.
Having the definitions sit in the `net/gnrc/sixlowpan/frag.h` header
does not make much sense, when using Selective Fragment Forwarding
(and the fragmentation buffer already includes a
`net/gnrc/sixlowpan/frag/stats.h` header), so they are moved to their
own header. Since with this change it makes more sense to have the
statistics stored in their own sub-module, the pseudo-module is also
actualized.
When the destination address is the loopback address (`::1`) in GNRC
the selected network interface typically is `NULL`, as with GNRC no
loopback interface de facto exists. So the assertion when checking if
the source address is valid if `netif != NULL` fails on that check.
This change fixes that issue by checking if the destination address is
the loopback address, before checking the validity of the source
address.
This fits with the semantics of this function which doesn't provide or
uses any state of the reassembly buffer provided by the user, but finds
the entry itself and then removes it. This gives the user no chance to
remove the packet in the reassembly buffer entry, so
`gnrc_sixlowpan_frag_rb_rm_by_datagram()` has to release the packet
(other than `gnrc_sixlowpan_frag_rb_remove()` where not releasing the
packet is desired as it might be handed up to an upper layer).
This allows to set a timer between the completion of a datagram in the
reassembly buffer and the deletion of the corresponding reassembly
buffer entry. This allows to ignore potentially late incoming link-layer
duplicates of fragments of the datagram that then will have the
reassembly buffer entry be blocked.
This was noted in this [discussion] for classic 6LoWPAN reassembly (and
minimal fragment forwarding) and is recommended in the current
[selective fragment recovery draft][SFR draft].
[discussion]: https://mailarchive.ietf.org/arch/msg/6lo/Ez0tzZDqawVn6AFhYzAFWUOtJns
[SFR draft]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-6
The name `fragment_msg` or `frag_msg`/`msg_frag` always to me was a bit
misplaced, as it basically implements an asynchronous fragmentation
buffer and doesn't necessarily have anything to do with messages.
This change
1. changes the name to `fb` (for fragmentation buffer)
2. factors its code out to its own sub-module so it can be re-used by
other 6LoWPAN fragmentation schemes like [Selective Fragment
Recovery]
[Selective Fragment Recovery]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05
