Hello, Joe, Thanks so much for your review! -- Please find my responses in-line... On 08/26/2016 04:29 PM, Joe Touch wrote: > > Document: draft-ietf-6man-deprecate-atomfrag-generation > Title: Generation of IPv6 Atomic Fragments Considered Harmful > Reviewer: J. Touch > Review Date: August 26, 2016 > IETF Last Call Date: August 8, 2016 > > Summary: This draft is on the right track but has open issues, described > in the review. > > The document has no issues directly applicable to transport protocols. > The impact on transports is indirect, in the ability of RFC 6145-style > IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with > IPv4-side fragmentation. > > However, there are some important non-transport issues that are noted below. > > Major issues: > > The impact of this change does not appear to have been explored. Section > 3 ends with a claim that links where this translation issue would be a > problem are rare, but there is no evidence presented as to whether > current RFC 6145 translators would be capable of complying with the > changes in this doc, e.g., to be able to generate IPv4 IDs as needed. > I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 > ID generation MUST be supported (and used), rather than MAY. RFC 6145 has been revised as RFC7915. > The document concludes that the translator should create IPv4 IDs rather > than relying on atomic fragments as a source of that information (as per > RFC2460) because there is no benefit, but are two reasons why this > method is directly hazardous as well: 1) RFC 2460 does not require that > the IPv6 ID field is generated to ensure that the low 16-bits are unique > as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 > translation could result in collisions where two distinct IPv6 > destinations are translated into the same IPv4 address, such that IDs > that might have been generated to be unique in the IPv6 context could > end up colliding when used in the translated IPv4 context. I.e., this > does not require ECMP as implied in Section 3. mmm.. not sure I follow. When we refer to ECMP in Section 3 we're actually describing the only possible scenario in which relying on the ID in the Frag Header could be of use (i.e., possibly result in lower collision rates). > Minor issues: > > IMO, it remains unwise to continue to imply that networks should treat > packets with fragment headers as an attack. Fragmentation support is > critical to tunneling (see draft-ietf-intarea-tunnels) and we need to > find ways to support their use safely. The text should be edited to > explain that the primary motivation here is to avoid generating > erroneous IPv4 ID fields, rather than to react to the incorrect > classification of fragment headers as incompatible with the Internet. Not sure what you mean. We're not implying that packets employing FH are an attack. FWIW, I don't personally think so. We do think that, when employing fragmentation, you open the door to a number of attack vectors. See e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. > The claim that links with IPv6 MTUs smaller than 1260 are rare needs to > be supported with evidence. I appreciate that such evidence may be > difficult to observe. In the absence of evidence, the statement should > be more clear that there is no evidence to the contrary -- which is not > the same as being able to claim that they *are* in fact rare. I see your point. Any suggestion on how to tweak the text? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492