Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@xxxxxxx] > Sent: Tuesday, February 07, 2017 11:53 AM > To: Templin, Fred L <Fred.L.Templin@xxxxxxxxxx>; otroan@xxxxxxxxxxxxx; Eggert, Lars <lars@xxxxxxxxxx> > Cc: tsv-area@xxxxxxxx; 6man-chairs@xxxxxxxx; 6man WG <ipv6@xxxxxxxx>; ietf@xxxxxxxx; draft-ietf-6man-rfc1981bis@xxxxxxxx > 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 > > fred.l.templin@xxxxxxxxxx > > > >> -----Original Message----- > >> From: tsv-area [mailto:tsv-area-bounces@xxxxxxxx] On Behalf Of Joe Touch > >> Sent: Tuesday, February 07, 2017 10:26 AM > >> To: otroan@xxxxxxxxxxxxx; Eggert, Lars <lars@xxxxxxxxxx> > >> Cc: tsv-area@xxxxxxxx; 6man-chairs@xxxxxxxx; 6man WG <ipv6@xxxxxxxx>; ietf@xxxxxxxx; draft-ietf-6man-rfc1981bis@xxxxxxxx > >> 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, otroan@xxxxxxxxxxxxx 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 > >> > > >