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

[Joe Touch <touch@xxxxxxx>]

On 2/7/2017 11:20 AM, otroan@xxxxxxxxxxxxx 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].  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