There is a forward-compatibility problem lurking in the
fragmentation specified by RFC 4944. In the RFC, fragment
headers include sizes and offsets that are relative to the
uncompressed datagram, and not the compressed version that
is actually being communicated. If a node receives a
fragmented datagram which includes a compressed next header
that the node does not know how to uncompress, the node may
not be able to determine if it has received all of the
fragments. It knows neither the length of the compressed
datagram or the total number of fragments.
Further, the RFC states:
Similarly, when a node first receives a fragment with a
given datagram_tag, it starts a reassembly timer. When
this time expires, if the entire packet has not been
reassembled, the existing fragments MUST be discarded and
the reassembly state MUST be flushed.
This requirement assumes that the receiver is able to
determine when it has received a complete datagram.
My main concern is the possibility of compressing TCP
headers at some time in the future. Pre-existing devices
would not necessarily be able to forward packets with
compressed TCP headers.
This could be fixed in several ways, such as using the
compressed sizes and offsets instead of the uncompressed
ones, or including the number of fragments in the first
fragment header.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
