ietf
[Top] [All Lists]

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

2017-02-07 13:58:20
Hi Joe,

-----Original Message-----
From: Joe Touch [mailto:touch(_at_)isi(_dot_)edu]
Sent: Tuesday, February 07, 2017 11:53 AM
To: Templin, Fred L <Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com>; 
otroan(_at_)employees(_dot_)org; Eggert, Lars <lars(_at_)netapp(_dot_)com>
Cc: tsv-area(_at_)ietf(_dot_)org; 6man-chairs(_at_)ietf(_dot_)org; 6man WG 
<ipv6(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org; 
draft-ietf-6man-rfc1981bis(_at_)ietf(_dot_)org
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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

-----Original Message-----
From: tsv-area [mailto:tsv-area-bounces(_at_)ietf(_dot_)org] On Behalf Of 
Joe Touch
Sent: Tuesday, February 07, 2017 10:26 AM
To: otroan(_at_)employees(_dot_)org; Eggert, Lars 
<lars(_at_)netapp(_dot_)com>
Cc: tsv-area(_at_)ietf(_dot_)org; 6man-chairs(_at_)ietf(_dot_)org; 6man WG 
<ipv6(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org; 
draft-ietf-6man-rfc1981bis(_at_)ietf(_dot_)org
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(_at_)employees(_dot_)org 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






<Prev in Thread] Current Thread [Next in Thread>