Skip to main content

Telechat Review of draft-ietf-6man-rfc1981bis-04
review-ietf-6man-rfc1981bis-04-tsvart-telechat-touch-2017-03-28-00

Request Review of draft-ietf-6man-rfc1981bis
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2017-02-28
Requested 2017-02-09
Authors Jack McCann <>, Stephen E. Deering <>, Jeffrey Mogul <>, Bob Hinden
I-D last updated 2017-03-28
Completed reviews Intdir Early review of -03 by Donald E. Eastlake 3rd (diff)
Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Tsvart Telechat review of -04 by Dr. Joseph D. Touch (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Telechat review of -06 by Rifaat Shekh-Yusef (diff)
Genart Telechat review of -06 by Stewart Bryant (diff)
Assignment Reviewer Dr. Joseph D. Touch
State Completed
Request Telechat review on draft-ietf-6man-rfc1981bis by Transport Area Review Team Assigned
Reviewed revision 04 (document currently at 08)
Result Not ready
Completed 2017-03-28
review-ietf-6man-rfc1981bis-04-tsvart-telechat-touch-2017-03-28-00
Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Joe Touch
Review Date: February 15, 2017
IETF LC End Date: March 3, 2017
IESG Telechat date: February 28, 2017

Review result: significant issues

NOTE: some of this review is informed by tracking some of the issues raised by
others on the IETF list, notably Gorry Fairhurst.

Major issues:

1) the current text is insufficiently realistic about the (in)ability of this
mechanism to operate in current networks, regardless of the support for
generating ICMPs at routers or PMTUD support at endpoints, due to ICMP
filtering for security reasons. [this comment is already being addressed by
consensus text]

2) the current text is insufficiently clear on on the difference between the
path MTU, which determines the largest supported IPv6 fragment, vs. the
effective MTU to receive (EMTU_R), which determines the largest IP packet that
can transit between the source and destination. The document should be more
explicit throughput about its goal being to manage or avoid IPv6 source
fragmentation rather than about source to destination packet maximums, and in
specific in clearly referring to maximum fragments or atomic packets rather
than maximum packets.

E.g.: see the following text, which is incorrect in its current form:
   Nodes not implementing Path MTU Discovery use the IPv6 minimum link
   MTU defined in [I-D.ietf-6man-rfc2460bis
<https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-04#ref-I-D.ietf-6man-rfc2460bis>]
as the maximum packet size.

The value used by either Path MTU Discovery or its default represents the path
MTU, which is the largest IPv6 *fragment* (or atomic packet, see RFC6864) that
can be supported on the path between the endpoints. The maximum IP packet size
is limited by the effective MTU to receive (EMTU_R) [RFC1122], which is at
least 1500 bytes for IPv6 and not necessarily related to the link MTUs. The
text should also clearly indicate that there is no ICMP mechanism for
determining larger EMTU_R support.

E.g., the following text is also incorrect in its current form:
   The value sent in the TCP MSS option is independent of the PMTU.
   This MSS option value is used by the other end of the connection,
   which may be using an unrelated PMTU value.

The first sentence is correct because TCP MSS is related to EMTU_R (and needs
to account for headers, as per RFC6691), and EMTU_R is not directly related to
the PMTU (except that it would never be smaller than the PMTU). The MSS option
is calculated from EMTU_R, not PMTU.

In addition, it should be noted that ICMPv6 PTB messages are NOT sent when
source fragmentation is enabled.

3. need verification of current support for some features, esp. regarding TCP
and NFS interactions See Gorry's note of 2/14/17

4. the concept of a single path MTU value between two IP addresses does not
account for multipath routing, e.g., ECMP (as currently deployed, noted in
RFC7690, which should be cited) or BANANA (and its solutions in development)
See Fred Templin's posts on this on 2/15/17

Minor issues:

- some of the updates and/or current text could be updated to reflect current
terminology or practice. See Gorry Fairhursts's post of 2/14/17

- fragmentation, while considered harmful and costly, is absolutely necessary
to support tunnels even in the presence of PMTUD. The text on this issue should
reflect this reality.

- the requirement that transports be notified of PTB messages might usefully
cite the corresponding IPv4, TCP, and UDP sections of RFC1122

- section 5.4 should cite and include context from RFC6691, especially
including a discussion of the impact of variable IP EHs on the interaction
between TCP MSS and ICMP PTB

--