"Carles Gomez Montenegro" <[email protected]> writes: > This document proposes a more lightweight and compact 6LoWPAN > fragmentation header, compared with the one defined in RFC 4944.
This seems like an improvement to me, though I'm new here. But this is a good time to ask my newbie question: I see this definition of the "datagram size" field: datagram_size: This 11-bit field encodes the size of the entire IP packet before link-layer fragmentation (but after IP layer fragmentation). For IPv6, the datagram size SHALL be 40 octets (the size of the uncompressed IPv6 header) more than the value of Payload Length in the IPv6 header [RFC4944] of the packet. Note that this packet may already be fragmented by hosts involved in the communication, i.e., this field needs to encode a maximum length of 1280 octets (the required by IPv6). Naively, it seems to me that link fragmentation is at a layer lower than link compression (e.g., LOWPAN_IPHC), so this datagram_size value is the length of the IPv6 packet (possibly an IPv6 fragment) as compressed by LOWPAN_IPHC. If that is so, the above text isn't quite right, as e.g. the compressed packet might be shorter than the (reconstructed) Payload Length in the IPv6 header. Now maybe I'm wrong, and "datagram size" is the length of the uncompressed IPv6 packet, but then I don't see how the receiver is to know when all of the fragments have arrived. Dale _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
