Re: Review of draft-ietf-6man-rfc1981bis-02

[Bob Hinden <[e-mail]>]

Tim,

Thanks for the review.

The changes to RFC1981 were intended to be limited to only include two things:

     Remove Note about a Packet Too Big message reporting a next-
     hop MTU that is less than the IPv6 minimum link MTU.  This
     was removed from [I-D.ietf-6man-rfc2460bis].

     Include a link to RFC4821 along with a short summary of what
     it does.

Most of your comments are on the original text and go well beyond this.  I don’t think they are in scope.

I also note that this is currently at Draft Standard, so questions about implementations have already been answered.

Comments below.

Thanks,
Bob


> On Jul 18, 2016, at 4:00 AM, Tim Chown <[e-mail]> wrote:
> 
> Hi,
> 
> Ole asked for a review of draft-ietf-6man-rfc1981bis-02.
> 
> Overall, the document looks close to being ready. But an important open question is whether PMTUD meets all the criteria for promotion to IS, as per RFC6410, i.e. that it has "a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community” and it has "widespread deployment and successful operational experience”. The question is on the word “successful”, given the robustness issues of PTB message transmission and receipt.

I think it does meet the criteria.  There are clearly issues with ICMP on the Internet, but the mechanism defined here works fine as long as ICMP are returned.  This document describes specifies PMTUD.

> 
> Related, one general comment is the level to which PLPMTUD (RFC4821) is ‘pushed’ in this document. It is mentioned in Section 1, but then not elsewhere in the document, where Packetization Layer PMTUD issues are discussed in a few places, e.g. Section 5.1 paragraph 2 which seems to suggest not using the 4821 approach.  Some consistency might be desirable here?

It is not being “pushed” it is being noted.  The intent as noted above was to add a note about PLPMTUD, not rewrite RFC1981.

If someone want to write a new draft contrasting the two approaches and make recommendations about how PMTUD and PLPMTUD along with other techniques should be used, that would be useful.  However, I don’t think it should be in RFC1981bis.

> 
> There is a large "Implementation Issues" section (Section 5), from the node’s perspective, but not much that I can see on handling of PMTUD-related messages (PTB) by nodes on a path from the reporter to the original packet sender. There’s a little on this in the Security Considerations. Is there, for example, value in adding a reference to RFC4890 somewhere, and that failure of sites to adhere to 4890 is a reason for using the 4821 approach?

As described above, I think this is out of scope.  There was a lot of discussion on the list on how PLPMTUD should be cited, that resulted in the current text.

> 
> Other comments:

I didn’t see any comments about the changes as noted above, they appear to be about the rest of RFC1981.

> 
> Section 1:
> 
> p.3 does the minimal implementation text belong here, or in the IPv6 Node Requirements document (which is also under revision)?
> 
> p.3 after the “Nodes not implementing…” paragraph, is it worth noting that use of 1280 MTU gives some level of robustness/predictability at the expense of reduced performance? A 1280 MTU is being used in practice in a number of scenarios/deployments. And in 2460-bis we have text that discourages fragmentation and prefers transmission of 1280 MTU non-fragmented packets (section 5, penultimate paragraph).
> 
> p.3 the note here on PLPMTUD (RFC4821) is appropriate, but as stated above, is this sentiment carried consistently through the rest of the document?  As it stands, it seems this note was parachuted in here, without other parts of 1981bis being updated to reflect the addition.
> 

> p.3 further, is use of one, either, or both approaches recommended, given the vagueness of the text about “delivery of ICMP messages not being assured” (for some value of “assured”)?  e.g. RFC4821 says it relaxes the requirements of RFC1981 and “resolves robustness problems”, but the text here doesn’t go further.  Does it need to?
> 

> Section 4:
> 
> p.6 do we have confidence that the 5 minute ‘MUST’ here is observed in common implementations?  (I don’t know, but if moving to IS we should check on existing practice?)
> 

> Section 5:
> 
> p.7 Second para in 5.1, as above, the text isn’t wholly in sync with advice on use of RFC4821?
> 
> p.7 last para of 5.1, in 2460-bis we say unnecessary fragmentation is “discouraged”.  A reference to [FRAG] is used, but is dated; there was also draft-bonica-6man-frag-deprecate-02, which expresses sentiment but was considered too “drastic" to be adopted by 6man.
> 
> p.8 if ND is mentioned here, should we cite RFC6980 on not fragmenting ND messages?
> 
> p.8 there’s mention here of RH0, which of course is deprecated; there are other valid RH types though, but this text needs updating to remove reference to RH0. It might also be worth adding a pointer here to the text in 2460-bis about not by default using the reverse path from any RH to send an ICMP message back to the sender (section 8.4 of 2460-bis)?
> 
> p.10 In 5.4, TCP layer interactions, referencing RFC7414 might be useful reinforcement.
> 
> p.10 do we have examples of the 10 minute rule on stale PMTU information being implemented, and feedback from that? (Again, I don’t know, but…)
> 
> p.11 there’s more packetization layer commentary here in the bottom half of the page; again how does this sit with RFC4821?
> 
> p.12 is it worth a Transport Area person reviewing the examples of other transport protocols given here, and adding more topical examples?
> 
> Section 6:
> 
> p.13 while a ‘malicious party’ may cause problems by stopping a ‘victim’ receiving Packet Too Big messages, failure of sites to adhere to RFC4890 is probably a more likely cause. Should this be mentioned somewhere?
> 
> p.13 is it worth adding a note about nodes on a path inserting an EH potentially causing PTB messages to go to the original source and not the ‘offender’ that made the packet too big?
> 
> Tim
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------