[art] Artart last call review of draft-ietf-6man-mtu-option-13

[Bernard Aboba via Datatracker <[e-mail]>]

Reviewer: Bernard Aboba
Review result: Ready with Issues

Document: draft-ietf-6man-mtu-option-13
Reviewer: Bernard Aboba
Result: Ready with Issues

This document proposes an experimental mechanism to add a new Path MTU
Hop-by-Hop option to IPv6.

As noted in Section 2, the IPv6 PMTU discovery mechanisms defined in RFC 8201
is known to fail when nodes in the network do not send ICMP Packet Too Big
(PTB) messages, or where ICMP messages are rate limited, or where there is no
return path to the source host. As noted in Section 2, the proposed mechanism
does not replace PLPPMTUD (RFC 4821) or Datagram PLPMTUD (RFC 8899), both of
which do not rely on ICMP messages, but do require a return path to the source
host.

The proposed mechanism does not rely on reception of ICMPv6 PTB messages and as
noted in Section 6.3.5, it has advantages over PLPPMTUD and DPLPMTUD in
detecting path changes, since the option consumes less capacity than a
full-sized probe packet.

However, the proposed mechanism does rely on widespread implementation of the
Hop-by-Hop option.  Where the Hop-by-Hop option is implemented sporadically,
the proposed mechanism could return a misleading result. This represents a
major weakness of the proposed approach. As noted in RFC 5218 Section 2.1.2,
one of the characteristics of successful protocols is incremental
deployability, where early adopters can gain some benefit even though the rest
of the Internet does not support the protocol. In this case, the incremental
benefits are limited (or even negative, due to the potential for misleading
results), which could limit the motivation for it to be widely deployed.
Section 10 mentions two implementations, but does not indicate adoption by
router vendors.

Past history is also sobering. A similar approach was proposed in 1988 (RFC
1063), but was never widely implemented, and was therefore obsoleted by RF 1191
in 1990.