Early Review of draft-ietf-6man-deprecate-atomfrag-generation-06
review-ietf-6man-deprecate-atomfrag-generation-06-intdir-early-bernardos-2016-05-02-00

Hi,

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/direc


torate.html.

Overall, the document is mature, well written and I find it useful. I
do not see any reason to hold up publication.

Some minor detailed suggestions follow:

- Section 1: The text says: 'Section 5 of [RFC2460] states that, when a
host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising
an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not
required to reduce the assumed Path-MTU, but must simply include a
Fragment Header in all subsequent packets sent to that destination.'

RFC2460 actually says 'In response to an IPv6 packet that is sent to an
IPv4 destination (i.e., a packet that undergoes translation from IPv6
to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280.'

While the document states later that 'an IPv6 node cannot easily limit
its exposure to the aforementioned attack vector by only generating
IPv6 atomic fragments towards IPv4 destinations behind a stateless
translator', it would help the reader to add that piece of context from
the very beginning of the document.

- Section 2: Again, I think it would help adding the context about
RFC2460 using atomic fragments only for the purpose of helping an IPv6-
to-IPv4 translating router can obtain a suitable Identification value
to use in resulting IPv4 fragments.

- Section 3: when discussing IPv4 Identification collision rates, it
would be helpful adding some numbers/equations there to get an idea of
what rates we are talking about.

- Appendix A: what does 'Linux kernel current' mean? This is very
minor, as this section is probably to be removed, but in case it
remains after publication as RFC, current should be replaced by the
kernel version number.

Thanks,

Carlos