Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-6man-rfc1981bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-6man-rfc1981bis-06.txt

OVERALL
I see in the shepherd's writeup that you have opted not to cite RFC
2119, but that makes the mixed case use of SHOULD/MUST even more
confusing. I would suggest that at minimum you go through the document
and evaluate whether each should/must should be capitalized, though I
would prefer a cite to 2119.

For instance:
   changed.  Therefore, attempts to detect increases in a path's PMTU
   should be done infrequently.

Is this normative?


I also share the concerns others have raised about whether, given the
actual state of PMTU this is something we should be making IS, but
I'm willing to bow to the majority here.


S 3.
   Note that Path MTU Discovery must be performed even in cases where a
   node "thinks" a destination is attached to the same link as itself.

I think you need to qualify this must because you just said above that
you don't need to if you use the minimum. Perhaps:

   Note that even when a node "thinks" a destination is attached to
   the same link as itself, it might have a PMTU lower than the
   link MTU...


S 4.

   Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
   messages to ensure these are received in response to transmitted
   traffic (i.e., a reported error condition that corresponds to an
IPv6
   packet actually sent by the application) per [ICMPv6].

This seems like it ought to be a MUST. Is there a good reason why
it is not? Perhaps also a cite to how one validates.


   When a node receives a Packet Too Big message, it MUST reduce its

a valid Packet Too Big message, I think because in graf 2 you say you
should validate.


   elicit Packet Too Big messages.  Since each of these messages (and
   the dropped packets they respond to) consume network resources, the
   node MUST force the Path MTU Discovery process to end.

It's not clear to me what the requirement is.

   Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
   as possible.  Nodes MAY detect increases in PMTU, but because doing

Same thing, what are you requiring. How could I be nonconformant to
this?

S 5.
   This section discusses a number of issues related to the
   implementation of Path MTU Discovery.  This is not a specification,
   but rather a set of notes provided as an aid for implementers.

However, this section contains a lot of normative language. Is that all
non-normative?


S 5.3.
   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.

Is this really good advice for TCP? It seems like if you have a
situation where it required several attempts to get the true PMTU (for
instance, if you have successively narrower tunnels), then a PMTU
reset could have a pretty material impact on throughput.


S 6.
      dropped.  A node, however, should never raise its estimate of the
      PMTU based on a Packet Too Big message, so should not be
      vulnerable to this attack.

I get that this is now not a normative statement but rather a claim
about what nodes who follow the MUST NOT in S 4, but it might still
be better to make it a MUST to avoid confusion.