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

[Tim Chown <[e-mail]>]

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. 

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?

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?

Other comments:

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