I've reviewed draft-ietf-6man-ipv6-atomic-fragments-03.txt and believe the document is "Ready with nits". From a security perspective, one could desire more discussion in the document but I do not believe significant attention is required. Document summary: The document is about special kind of IPv6 fragment; a fragment that claim to be offset 0 of the payload and also to be the last fragment. The document says that those fragments can be reassembled without waiting for any other fragment. The document is another tweak for the IPv6 fragmentation rules. /Simon Caveat: I'm not an IPv6 expert so the issues below may just be due to my misunderstanding of how things work. A sufficient response to some of the issues below may just be that I got it all wrong, although if that is the case, some explanation for my education would be appreciated. MINOR ISSUES: 1) The document does a good job describing how attackers can trigger atomic fragments, which makes it possible to apply fragmention-based attacks to normal traffic. But there is no details about fragmentation-based attacks, neither what is gained nor how they are mounted. It refers to informational documents [I-D.gont-6man-predictable-fragment-id] and [CPNI-IPv6] for the attacks, which I have not reviewed. Thus the abstract's claim that "the document discuss [...] the corresponding security implications" seems erradic since the discussion does not happen in this document. The Security Considerations does not describe any complete attack either. It is possible, perhaps likely, that fragmentation-based attacks are well-known to anyone working with IPv6 that they do not need to be explained in this document. As an out-sider, though, I was left with the feeling that the attack this document attempts to protect against is not actually described. If a short description of one complete attack could be added, that would have helped me. 2) This is actually more of a question about the new rule text. I'm having trouble understanding what should happen in the following situation: * A host has a fragment with fragment identification X in its cache, with fragment offset 42 and M=1 indicating there are other outstanding fragments. * A host has received an atomic fragment (i.e, fragment offset 0 and M=0) with the same fragment identification X. * A host never receives any more fragments with the fragment identification X. RFC 2460 says: If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded. If the first fragment (i.e., the one with a Fragment Offset of zero) has been received, an ICMP Time Exceeded -- Fragment Reassembly Time Exceeded message should be sent to the source of that fragment. Now given the following updated text in section 4: A host that receives an IPv6 packet which includes a Fragment Header with the "Fragment Offset" equal to 0 and the "M" bit equal to 0 MUST process such packet in isolation from any other packets/ fragments, even if such packets/fragments contain the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. The atomic fragment should be dealt with in isolation, so it is reassembled immediately. Now, after 60 seconds, what should the host do? Should it send an ICMP Time Exceeded or not? It has already completed assembly but it is also waiting for more fragments. 3) As a consequence of the previous point, I'm left uncertain about how the updated rule interacts with the requirements in RFC 5722 about overlapping fragments. If overlapping payloads should cause packets to be dropped, this is no longer the case if atomic fragments are "let through" the fragmentation logic. 4) Section 2: Offset set to 0 and the M bit set to 0. ^^^ RFC 2460 uses the term "M flag", not "M bit". 5) o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destinations Cache is usually updated to ^^^^^^^^^^^^^^^^^^ reflect that any subsequent packets to such destination should include a Fragment Header. This means that a single ICMPv6 Where is "Destinations Cache" defined? The phrase does not have any specific meaning to me, and I cannot find it in any of the normative references. The use of upper case suggests to me that some well defined meaning is intended. Without understanding that term, I don't follow the rest of the paragraph. 6) Additionally, if any fragments with the same set {IPV6 Source ^ Typo, 'v'.