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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
