Hi, Eric, Thanks so much for your feedback! -- Please find my comments in-line...
On 08/14/2012 11:14 AM, Eric Vyncke (evyncke) wrote: > A couple of quick comments: - section 2: I would love to have data to > back the point of 'Many implementations fail to perform validation > checks on the received ICMPv6 error messages' (such as adding a > reference to your appendix) What data, specifically, would you expect? -- A list of vulnerable implementations or the like? You may want to try the icmp6 tool in the IPv6 toolkit <http://www.si6networks.com/tools> to fire e.g. ICMPv6 PTB, and see that they are honored without e.g. checking the embedded TCP sequence number. - section 3: it would be nice to add some > text about the case where a packet is duplicated by the network > (could occur in rare circumstances) and one copy is fragmented (not > an atomic fragment) and the other copy is not (atomic fragment) > because of different path There's no fragmentation in routers, and hence this is not possible -- for instance, this is part of the rationale for RFC 5722. - section 3: not sure what is meant by 'FH > should (no uppercase?) be removed by the receiving host', This is the same as "performing fragmentation using only the atomic fragment"... the Next-Header field in the IPv6 fixed header should be changed to the value of the Next-Header in the FH, BTW. > on the > contrary, I would prefer to keep the FH in the packet (some apps may > need it) but immediately deliver the full packet to the upper layer - Do such stacks keep the FH for normal fragmented traffic? -- If so, how are each of the values (FOffset, etc.) selected? (Bottom-line: if this doesn't happen for normal fragmented traffic, I don't think we should make atomic fragments a special case). > section 3: it would be nice if some explanations were given why a > host receiving such an atomic fragment should not discard the > matching real fragments... Well, we don't really take a stance regarding what to do with the matching fragments. Performance-wise you may want to avoid searching through the queued fragments. Thoughts? > I tend to believe that upper layer (TCP > notably) will reject the second one if the sequence number match Not sure what you mean... > May I also suggest to integrate this I-D into the more generic > draft-gont-6man-predictable-fragment-id ? It will make the task of > implementers easier if both I-D are merged. I personally believe that both I-Ds are orthogonal. And also, procedurally-wise, at this point in time (past WGLC) we'll be better off progressing this one small document than trying to merge it with draft-gont-6man-predictable-fragment-id (which is not yet a wg item). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
