Re: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492