Hi Joe, In my understanding, RFC4821 does not adequately address scenarios where the probe packets may (for legitimate reasons) take a different path than the data packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is not only a consideration for tunnels, but also for path MTU sharing between transport layer sessions where an MTU learned by a first session is shared with a second session bound for the same destination. In that case, the probes of the first session may take a different path than the data packets of the second session, and a black hole is possible.
Thanks - Fred [email protected] > -----Original Message----- > From: tsv-area [mailto:[email protected]] On Behalf Of Joe Touch > Sent: Tuesday, February 07, 2017 10:26 AM > To: [email protected]; Eggert, Lars <[email protected]> > Cc: [email protected]; [email protected]; 6man WG <[email protected]>; > [email protected]; [email protected] > Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU > Discovery for IP version 6) to Internet Standard > > > > On 2/4/2017 10:40 AM, [email protected] wrote: > > Lars, > > > >>> 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. > > > 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) > > Joe >
