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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]