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
signature.asc
Description: Message signed with OpenPGP