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

[Bob Hinden <[e-mail]>]

Tim,

Thanks for the detailed review.  Comments below.

Bob

> On Jul 18, 2016, at 12:08 AM, Tim Chown <[e-mail]> wrote:
> 
> 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.

This is introductory text describing the differences from IPv4, I don’t think a reference is needed here.  Multicast addresses are defined in RFC2491 (and bis).

> 
> 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.

This text is describing the differences from IPv4, and I think it continues to be true.

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

I agree, but I think s/for which/that/ is better.

> 
> 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).

I agree the the Routing Header should not have been removed from the list of required EHs.  I will add it back in, but not be specific about which type of RH, that is defined in the IANA table as noted in Section 4.4

> 
> Section 4:
> 
> p.6 there is now more than a “small number” of EHs defined.

Small is a relative term.

> 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?

There is a pointer at the end of Section 4.  I think this is adequate.

> 
> 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.

Let’s defer this to a separate thread on the general topic of header insertion.  It will be in a separate email.

> 
> 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, …)?

I don’t think so, this text is based on RFC7045.

> 
> 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?

A node that is required by RFC2460bis to process a header must discard it if it encounters an unrecognized next header value. RFC7045 defines additional reasons why packet might be discarded.

> 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).

No, as described above.

> 
> 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).
> 

I don’t see any problem with the current text.


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

It is saying that if the packet is too big for the next link, it must be discarded and a PTB be sent.  I think this should continue to be said here, since it is forwarding a packet that was destined for yourself, and it might be misunderstood that the node could fragment at this point.

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

I have been trying to avoid making unnecessary changes to the original 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.

This was a case where I incorporated the ideas of the update and kept the terminology as close as possible as the original.  There were several updates that had to be incorporated.

I continue to think it reads OK.  The text you mention is on the next page.  A subtle change here is that this text doesn’t allow overlapping fragments to be created, unlike the origional, as the text separates the rules for the first and subsequent fragments.  The non-overlaping text is later because it should only happen if sent by a non-conforming or malicious sender.

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

No, RFC6980 doesn’t update RFC2460.  There is no other mention of ND in this document.

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

It is discussed in the text that follows the diagram.

> 
> 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?

One is about performing fragmentation, the second is about reassembly.  It needs to say it in both places.

“slinky” ?  Did you mean silently?  If so, the text at the bottom of page 19 says to discard (and doesn’t say to send an ICMP).

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

No, his was part of incorporating several updates.  I think this is clear.

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

Perhaps, but not sure it would clarify anything.

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

It sets an upper bound, that is “within 60 seconds”.  It does not say all fragments must be held for 60 seconds.

> 
> p.20 the fourth condition could cite RFC7112

See above.

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

I think that makes sense, I will add.  I need to think if the text on page 19 should then be removed.

> 
> 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?
> 

The text at the end of page 20 says:

  The following conditions are not expected to occur

So it is not expected to be common and they are usually the same.


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

I am not 100% sure, but think it is used.  But it is not something that has been updated.

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

It is the same format, and is noted in Appendix B.

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

I will look at rewriting this paragraph to make it clearer.

> 
> 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.
> 

Me too.


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

I also remember the discussion about deprecating IPv6 fragments, but think “discouraged” is fine.

> 
> Section 8:
> 
> p.26 add a reference to RFC6935 with respect to tunnels and UDP checksums?

The RFC2460bis documents brings in the replacement text from RFC6935 (this updating document was very clear as to the change), so I think only RFC6936 needs to be referenced and this was part of the replacement text (from RFC6935).

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

I don’t see any inconsistency.  This text discusses the differences between IPv6 and IPv4.

> 
> 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…)

As far as I know, it is consistent.



> 
> Best wishes,
> Tim
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------