Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

[[e-mail]]

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