Early Review of draft-ietf-6man-deprecate-atomfrag-generation-06
review-ietf-6man-deprecate-atomfrag-generation-06-intdir-early-lemon-2016-04-28-00

I am an assigned INT directorate reviewer for
draft-ietf-6man-deprecate-atomfrag-generation-06.txt

These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see

http://www.ietf.org/iesg/directorate.html

.

This document doesn’t appear to actually recommend a course of action other
than in the Abstract.   It seems to me that this document is arguing (perhaps?)
that firewalls should drop atomic fragments, or perhaps that hosts should.  
But it never gives any actual advice.

It seems to me that the document could be substantially improved by explicitly
saying what behaviors are being recommended here.   Otherwise, the statement in
the Abstract that this is intended to motivate changes to the core IPv6
protocol specifications seems to leave whoever does that with the task of
reading this document, thinking through the problem the authors have already
thought through, and trying to come up with the right changes to the base spec.

While doable, this seems unnecessary given that the authors have put a lot of
thought into this.  Even if the document were to recommend a course of action
that wasn’t ultimately followed, walking through the reasoning behind those
recommendations would likely be helpful.   Given that the document is
informational, this advice could be described as a recommendation for future
work, and not as advice to implementors.

It might also be useful, and would likely render any worries about this
document being treated as normative, if the authors were to talk about what to
do to clean up existing implementations if the decision is taken to retain the
atomic fragment functionality.

That said, the document is mature, and useful as written.   I do not see any
reason to hold up publication if the working group is unwilling or unable to
make the changes I’ve suggested.

Some minor detailed suggestions follow:

OLD:

  Once the attack

  packet has been sent, it will be the aforementioned routers

  themselves the ones dropping their own traffic.

NEW:

  Once the attack

  packet has been sent, the aforementioned routers

  will themselves be the ones dropping their own traffic.

  o  As noted in Section 3, SIIT [RFC6145] (including derivative

Expand SIIT acronym?

  2.  The IPv4 node is located behind an IPv4 link with an MTU smaller

      than 1260 bytes

It would be helpful to talk about when this might happen.   It’s not clear to
me that this is a plausible real-world scenario in these modern times, but if
it is it would be good to identify the situations in which the proposed change
will create operational problems.  I don't think that any use case you might
list here would lead the reader to conclude that therefore we need to keep
atomic fragments, but such use cases should be discussed, or the lack of any
known such use cases should be discussed, for completeness.