Review of draft-ietf-6man-rfc2460bis-05

[Tim Chown <[e-mail]>]

Hi,

Ole asked me to review draft-ietf-6man-rfc2460bis-05.

Generally, the document looks to be in good shape. Personally, I agree with the changes made. It looks close to being ready for the four week IETF Last Call, as per RFC6410.  The four key criteria for promotion to IS as listed in RFC6410 seem to have been met (widespread deployment with successful operational experience, errata addressed, no unused features that would greatly increase implementation complexity, and not IPR encumbered).

Where changes to RFC2460 have been made with respect to RFCs published since the original publication of RFC2460, there is some inconsistency as to whether those RFCs are explicitly cited, or their ‘message’ just incorporated as an update.  Some consistency would be desirable; specific occurrences are listed below.

The comments below are largely clarification in nature. 

Comments:

Section 1:

p.3 on the scope field for multicast addresses there could now be a reference to RFC7346.

p.3 the EH text should probably no longer mention “greater flexibility for introducing new options in the future”. In 1998 yes, but not now, with the benefit of hindsight. Later sections discuss this in more detail.

p.3 in the flow label text, delete ‘for’.

Section 3:

p.6 the Destination Address destination talks of the Routing Header, but this has now been removed from the list of EHs required for a ‘full implementation’ EHs on p.8. (see more on this below).

Section 4:

p.6 there is now more than a “small number” of EHs defined. This document only defines / discusses a small number explicitly, but a fuller list is included in RFC7045. I think it’s fine that we should keep 2460 just referring to the ‘core’ headers (the ones required for a 'full implementation’ on p.8), but there may be an argument to refer to RFC7045 as a pointer to the new “IPv6 Extension Header Types” list maintained by IANA. Or maybe that pointer should be in Section 9?

p.7 do we need to be clearer in the meaning of “processed” here? Is “examining” a form of “processing”.  It might read better if the RFC7045 Note was placed after the paragraph on p.8 that states the Hoby-by-Hop exception. 

p.7 note that firewalls would be an example of nodes that might process EHs beyond the HbH header. Do we need to be clear that 2460 talks of normal processing, not processing for security reasons (firewall, IDS, …)?

p.8 in the “If, as a result…” paragraph, is the text now contradictory to RFC7045, which says "If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header.”? The 2460-bis text implies a discard, while 7045 implies that shouldn’t happen unless as a result of configured policy?

p.8 should we be removing the Routing header from the list here? Yes, RH0 is deprecated, but I understand that SPRING is using the RH, and there are also the Type 2 and Type 3 RHs defined in RFC6275 (Mobility use) and RFC 6554 (RPL use).

p.9 the text saying “in any order” might be less ambiguous if stated as “appearing in any order” (i.e. emphasise the EHs are processed sequentially, no matter what order they are in, rather than the node processing the EHs in any order).

p.14 in the “If, after processing…” paragraph, isn’t this true regardless of alterations to the RH?  Is this superfluous?

p.15 the (*) note for “recently” looks a bit ugly. Just make it normal text?

p.16 A note about RFC7112 would be best placed after the “The Fragmentable Part” paragraph. As it stands, the RFC7112 principle (all EHs in the first frag) isn’t mentioned until further into the document, on p.17 item (3), and even then 7112 isn’t cited.  A note about not creating overlapping fragments could also be inserted here, as per RFC5722.

p.16 should we mention here that ND messages should not be fragmented, as per RFC6980, section 6?

p.17 this diagram emphasises the model that RFC7112 requires, with the EHs in the first frag.  Maybe note that in the text.

p.18 the “Fragments must not be created…” line is a duplication of the last paragraph on p.19.  Move that larger para forward?   Also perhaps note the requirement to slinky discard, as per RFC5722?

p.20 paragraph 2 should refer to RFC6946 on handling of atomic fragments?

p.20 I suggest numbering the four listed error conditions, for clarity.

p.20 is the 60 second rule commonly implemented? This seems a very high value, and could contribute to DoS effectiveness?

p.20 the fourth condition could cite RFC7112

p.20 add a fifth error condition of overlapping fragments, as per RFC5722?

p.21 para 2, is it common that such headers may differ?  The implication of p.17 point (1) is that they’d be the same?

p.22 is Next Header value 59 used in practice? (Just curious… it was omitted from RFC7045).

p.22 in section 4.8, cite RFC6564, which appears to be the format used in the latter part of that section.

p.23 “Defining new…” sentence duplicates the start of the paragraph?

Section 5:

p.24 Do we add a note here about PLPMTUD, or just leave that to RFC1981-bis? I would probably say the latter.

p.24 how strong is “discouraged”?  I remember well draft-bonica-6man-frag-deprecate-02 ;)

Section 8:

p.26 add a reference to RFC6935 with respect to tunnels and UDP checksums?

p.26 is the text in 8.2 consistent with the text on page 6 about the Hop Limit? 

p.27 is the text in 8.4 consistent with Type 2 and Type 3 RH use? (I don’t follow RPL in enough detail...)


Best wishes,
Tim