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

[Joe Touch <[e-mail]>]

On 2/7/2017 11:20 AM, [e-mail] wrote:
> Joe,
>
>>>>> 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.
> PLMTUD is unfortunately not a (complete) replacement of PMTUD.

PLMTUD is a directive to protocols above the IP layer; it isn't a single
protocol, so it wouldn't replace anything.

>
>>> 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)
> Is this the paragraph you are referring to?
>
>    PLPMTUD requires a separate,
>    direct control channel from the egress to the ingress that provides
>    positive feedback; the direct channel is not blocked by policy
>    filters and the positive feedback ensures fail-safe operation if
>    feedback messages are lost [RFC4821].
That is nowhere near section 5.5.2.

5.5.2 indicates places where RFC2473 has errors, esp. in how it
interprets the MTU of the tunnel as being defined by the MTU of the path
within the tunnel, rather than by the tunnel egress reassembly limit.

> I'm very much in favour of working on better ways of doing Path MTU discovery.
> A blanket statement of "use "PLMTUD" seems very premature though.
The point is that this document fails to indicate the current state of
PMTUD. It correctly notes that:

   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821 <https://tools.ietf.org/html/rfc4821>].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMP messages to a host is not assured.


IMO, it fails to note that this case - where ICMP messages are assured
along a path - is effectively a unicorn except within systems maintained
by a single entity.

> RFC1981 has 70 citations:
> http://www.arkko.com/tools/allstats/citations-rfc1981.html
>
> Could you expand on your view of how this pertains to advancing RFC1981?
It's called last call input. My input is that this document needs to be
more realistic in noting that, for all intents, ICMP-based MTU discovery
isn't viable and that other methods need to be *expected*, not just that
they're available.

Joe