Reviewer: Dave Thaler Review result: Ready with Issues The title implies the document specifies a forwarding mechanism, but it does not, it merely provides discussion of two mechanisms in other docs (RFC 4944 and draft-ietf-lwig-6lowpan-virtual-reassembly). I would recommend at least changing the title to be more clear as to the purpose of the doc. Technical confusion ------------------- 1) Page 3 says the reassembly buffer contains "the link-layer address that node B uses to forward the fragments". I cannot tell whether this is referring to B's link-layer address that it received the fragment on, or B's link-layer address that it uses as a source link-layer address for forwarding it on, or the link-layer address of the next hop to which B forwards. 2) Page 3 also says the reassembly buffer contains "the link-layer address of the next hop that is resolved on the first fragment". I found this similarly confusing. What does it mean to resolve something "on" the first fragment? Does it mean "during processing of the first fragment"? Maybe I missed it, but I couldn't find in RFC 4944 anywhere that says that it would do next-hop resolution before the datagram can be reassembled. That would seem like a waste, if the fragments are then discarded (e.g., due to timer expiry) without actually doing any forwarding. 3) Section 3 talks about "MAC address" specifically whereas section 1 always talked about the more generic "link-layer address". Why the inconsistency? 4) Section 3 talks about "a 1280-byte reassembly buffer for each packet", but section 2.2 talks assumes a "1 kB reassembly buffer". 1k != 1280 bytes. Why the inconsistency? 5) Section 3 explains that "the first fragment must always be forwarded first", but does not explain what the behavior is if a fragment other than the first fragment is received before the first fragment. Figure 1 shows that the fragments can be received out of order, since there fragment 6 is received before 5, which is received before 4. Presumably it is either queued or dropped. If it's queued, then section 4 is insufficient, which talks about an attacker generating a large number of bogus "fragment 1" fragments, since if you queue the first fragment received even if it's not "fragment 1", then the same attack presumably exists, it's not specific to "fragment 1" packets. Grammatical nits: ----------------- Abstract has "... to forwarding ...", which should be "to forward" or "for forwarding" Abstract has "to the virtual Reassembly Buffer", which seems incorrect both in terms of capitalization (since sectoin 3 has VRB) and grammar. Suggest "to using virtual reassembly buffers". Section 1, first paragraph: "though possibly" is likely a typo for "through possibly" Section 1, 6th paragraph: "a same datagram" is oddly worded. Suggest either "a datagram" or "the same datagram" Section 2.2, grammar issue in "Assuming 1 kB reassembly buffer". Either "buffers" plural or "Assuming a ..." -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
