Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, February 07, 2017 11:53 AM > To: Templin, Fred L <[email protected]>; [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 > > Hi, Fred, > > This is a separate issue with RFC4821, though.
Agreed. Fred Baker and I were discussing about whether an erratum should be filed. > My point for 1981bis is that it needs to be more clear that ICMP > blocking renders this technique ineffective for the most part. I'm not > saying that PLPMTUD is perfect or the only alternative, but this doc > should be more clear about its own viability. I could agree if suitable language could be adopted. Thanks - Fred > Joe > > > On 2/7/2017 11:45 AM, Templin, Fred L wrote: > > 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 > >> > > >
