Subject: Genart telechat review of draft-ietf-6man-rfc1981bis-06

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 Apr 2017 10:12:08 -0700

Reviewer: Stewart Bryant
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6man-rfc1981bis-??
Reviewer: Stewart Bryant
Review Date: 2017-04-24
IETF LC End Date: 2017-03-01
IESG Telechat date: 2017-05-11

Summary: This is can be published as is, but I think could be
improved.

I thank the authors you for dealing with most of my comments in the
previous round.
There are two unaddressed points that the IETF Chair may wish to
consider, and one
that I missed.

Major issues:
The text has a lot of RFC2119 language, but no RFC2119 declaration.
and the document seems inconsistent about when it uses RFC2119
language and
when it does not. This sends a mixed messages to authors if we are not

consistent on this point throughout the RFC Series.

=======

5.3.  Purging stale PMTU information

   Internetwork topology is dynamic; routes change over time.  While
the
   local representation of a path may remain constant, the actual
   path(s) in use may change.  Thus, PMTU information cached by a
node
   can become stale.

   If the stale PMTU value is too large, this will be discovered
almost
   immediately once a large enough packet is sent on the path.  No
such
   mechanism exists for realizing that a stale PMTU value is too
small,
   so an implementation should "age" cached values.  When a PMTU
value
   has not been decreased for a while (on the order of 10 minutes),
the
   PMTU estimate should be set to the MTU of the first-hop link, and
the
   packetization layers should be notified of the change.  This will
   cause the complete Path MTU Discovery process to take place again.

SB> I still worry that the impact of this advice is going to be a
disruption to what might
SB> be a critical service every 10 mins, and wonder if there should be
some advice along the 
SB> lines of noting the importance of service delivery as part of
deciding whether to
SB> test for bigger PMTU vs improving efficiency?

Minor issues:

 A node MUST NOT reduce its estimate of the Path MTU below the IPv6
 minimum link MTU.

SB> I missed this last time.
SB>
SB> Presumably you mean "A node MUST NOT reduce its estimate of the 
SB> Path MTU below the IPv6 minimum link MTU in response to such
SB> a message."
SB> 
SB> Otherwise I would have thought that this was entirely a matter 
SB> for the host whether it wanted to use a Path MTU below the IPv6 
SB> link minimum. Nothing breaks if the host takes a more conservative

SB> decision.
SB> 

Nits/editorial comments:  None.

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 11:26:00 -0700

Hi, Stewart,

> SB> Path MTU below the IPv6 minimum link MTU in response to such
This seems fine to me, FWIW - i.e., limiting the advice in this doc to
the mechanism in  this doc.

> SB> link minimum. Nothing breaks if the host takes a more conservative
I don't agree; the host at that point is violating RFC2460. It should
never think that an IPv6 link or path with an MTU below what RFC2460
requires is valid.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Apr 2017 09:48:43 +0100

> never think that an IPv6 link or path with an MTU below what RFC2460

That is as maybe, but a host can do more or less what it wants, so this 
is surely an
unenforceable constraint, or are you telling me that the receiving host 
MUST drop a
fragment that is shorter than this? In which case the question whether 
in practice
they do, and whether such a constraint is reasonable.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 11:35:12 -0700

Hi, Stewart,

On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>> ...
> That is as maybe, but a host can do more or less what it wants, so
> this is surely an
> unenforceable constraint, or are you telling me that the receiving
> host MUST drop a

A "path MTU" is a value calculated from information from various sources
(attached links, ICMP messages, and perhaps other information), but IMO
it's never appropriate to set a "path MTU" smaller than the limit
established by IPv6 for a single link.

Individual packets and fragments can be smaller than the MTU, of course.
Nothing forces fragments to push up against any MTU limit at all. But I
would not describe that has a host changing its path MTU; it's just
sending packets.

Joe

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Apr 2017 13:08:25 -0700

> On Apr 26, 2017, at 11:35 AM, Joe Touch <[email-masked]> wrote:
> 
> Hi, Stewart,
> 
> 

You are, of course, quoting RFC 1981:
   A node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

> would not describe that has a host changing its path MTU; it's just

I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 13:18:11 -0700

Hi, Fred,

On 4/26/2017 1:08 PM, Fred Baker wrote:
> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). 
While it might apply differently based on port-based routing, path MTU
is an IP concept. It sets IP limits (MTU is an IP-ism, including all its
variants, such as EMTU_S, EMTUR, etc. - from RFC1122), which then
cascades into TCP limits (MSS and MMS_*, again per RFC1122).

And it's not the largest packet - it's strictly the largest IP fragment.
Transport uses that as the limit on IP messages to avoid fragmentation.
Technically, though, PMTU could also be used by the IP layer to guide
source fragmentation if the transport layer presents messages that are
too large to fit in a single datagram.

> I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
TCP probably wouldn't, but UDP can, would, and does.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2017 08:30:12 +1200

> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under curr…

istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 13:33:53 -0700

> istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job…
IMO, the best thing is to loudly flag the path as no longer valid.

Either we have required minimums or not. If not, then we have a LOT of
new work to do.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 27 Apr 2017 13:36:25 +0100

On 26/04/2017 21:30, Brian E Carpenter wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

So this seems to me to be an argument of principle vs pragmatism, and in 
general pragmatism has served the Internet well so far.

I think pragmatism is what Fred and Brian arguing for. It is certainly 
the general approach that I support.

I think we have agreed that nothing actually breaks if the host takes a 
more conservative approach, and that the communications path is less 
likely to be disrupted if that is what the host does. I would have 
thought that we should write the text in such a way to "allow" a 
pragmatic mode of operation.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 09:57:43 -0700

On 4/27/2017 5:36 AM, Stewart Bryant wrote:
> ...
> So this seems to me to be an argument of principle vs pragmatism, and
> in general pragmatism has served the Internet well so far.
>

IMO, 1981bis should limit its advice to behavior in response to ICMPs, e.g.:

   In reaction to a received ICMP message, a node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

Doing otherwise presents too big an attack surface.

Any other advice on how an end system manages its idea of MTU or
otherwise overrides the 1981bis computation of path MTU should be
limited to host requirements documents, not this one.

Joe