Joe, >>>> My apologies: my comments were probably misleading. Certainly, this >>>> document is simply RFC1981 to Std, and hence recommending RFC4821 would >>>> be kind of ou of scope, here. >>>> >>>> That say, one might wonder to what extent, and for the general Internet, >>>> RFC1981 can be considered succesful (given the filtering of ICMP >>>> messages). -- i.e., at this point in time you wouldn't rely on RFC1981 >>>> (icmp-based pmtud) for path-mtu discovery. >>> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years. >> While I'm all in favour of PLMTUD. It doesn't seem like a complete solution. >> PMTUD on the other hand supports all protocols on top of IP. > If by "supports" you mean "doesn't work", then yes. That's why we now > have PLPMTUD. PLMTUD is unfortunately not a (complete) replacement of PMTUD. >> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example. > See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2 > > (yes, that doc has expired while we're preparing the 04 update, which > should be issued shortly) Is this the paragraph you are referring to? PLPMTUD requires a separate, direct control channel from the egress to the ingress that provides positive feedback; the direct channel is not blocked by policy filters and the positive feedback ensures fail-safe operation if feedback messages are lost [RFC4821]. I'm very much in favour of working on better ways of doing Path MTU discovery. A blanket statement of "use "PLMTUD" seems very premature though. RFC1981 has 70 citations: http://www.arkko.com/tools/allstats/citations-rfc1981.html Could you expand on your view of how this pertains to advancing RFC1981? Best regards, Ole
Attachment:
signature.asc
Description: Message signed with OpenPGP