Reviewer: Charlie Kaufman Review result: Has nits (though not worth holding it up for if there are no other problems) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposed to be an *experimental* RFC proposes an IPv6 header extension in which the path MTU is computed and returned (with the help of intermediate routers). If universally deployed, this mechanism has the potential to provide a more efficient and more reliable method for determining path MTU between two nodes. If deployed only sporadically, it provides another source of clues with respect to path MTU and use of the information might make determination of path MTU either more or less efficient and more or less reliable. A security concern is that on off-path node could potentially inject misinformation about MTU of a connection as some sort of denial of service attack. This I-D proposes a number of potential mechanisms to mitigate such an attack, including that if a packet is dropped by an application based on it failing some validation test, the information in the extension should be ignored. In practice, this might be difficult to implement because these operations are in different network layers. In particular, section 8.3 specifies that use of TLS can mitigate such attacks, but TLS integrity checks on data can occur only once in a large number of packets, and retroactively ignoring packets that occurred long in the past is unrealistic. The checks done by TCP, however, can do done in-line and would probably be effective. When doing IPsec tunneling, the path MTU cannot be updated in the inner header and therefore may be inaccurate. An IPsec implementation could - as with the congestion bit - translate information from an outer header to an inner header when decapsulating to accurately report this information. Doing so would require adjusting the path MTU to take into account the length of the IPsec header. Such a procedure is not described or recommended by this document, but could be in a subsequent document if this mechanism catches on. Found 1 nit: page 17: "When a forged packet cause a packet..." -> "When a forged packet causes a packet..." --Charlie