Early Review of draft-ietf-6man-deprecate-atomfrag-generation-06

Request Review of draft-ietf-6man-deprecate-atomfrag-generation
Requested rev. no specific revision (document currently at 08)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-08-22
Requested 2016-04-21
Authors Fernando Gont, Will LIU, Tore Anderson
Draft last updated 2016-04-28
Completed reviews Genart Last Call review of -07 by Joel Halpern (diff)
Intdir Early review of -06 by Carlos Bernardos (diff)
Intdir Early review of -06 by Ted Lemon (diff)
Secdir Last Call review of -06 by Klaas Wierenga (diff)
Assignment Reviewer Ted Lemon 
State Completed
Review review-ietf-6man-deprecate-atomfrag-generation-06-intdir-early-lemon-2016-04-28
Reviewed rev. 06 (document currently at 08)
Review result Ready
Review completed: 2016-04-28


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 



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:


  Once the attack

  packet has been sent, it will be the aforementioned routers

  themselves the ones dropping their own traffic.


  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.