Also, since a single NFS operation cannot be split across several UDP
   datagrams, certain operations (primarily, those operating on file
   names and directories) require a minimum payload size that if sent in
   a single packet would exceed the PMTU.  NFS implementations should
   not reduce the payload size below this threshold, even if Path MTU
   Discovery suggests a lower value.  In this case the payload will be
   fragmented by the IP layer.










 
RFC 1981              Path MTU Discovery for IPv6            August 1996


5.6. Management interface

   It is suggested that an implementation provide a way for a system
   utility program to:

   - Specify that Path MTU Discovery not be done on a given path.

   - Change the PMTU value associated with a given path.

   The former can be accomplished by associating a flag with the path;
   when a packet is sent on a path with this flag set, the IP layer does
   not send packets larger than the IPv6 minimum link MTU.

   These features might be used to work around an anomalous situation,
   or by a routing protocol implementation that is able to obtain Path
   MTU values.

   The implementation should also provide a way to change the timeout
   period for aging stale PMTU information.

6. Security Considerations

   This Path MTU Discovery mechanism makes possible two denial-of-
   service attacks, both based on a malicious party sending false Packet
   Too Big messages to a node.

   In the first attack, the false message indicates a PMTU much smaller
   than reality.  This should not entirely stop data flow, since the
   victim node should never set its PMTU estimate below the IPv6 minimum
   link MTU.  It will, however, result in suboptimal performance.

   In the second attack, the false message indicates a PMTU larger than
   reality.  If believed, this could cause temporary blockage as the
   victim sends packets that will be dropped by some router.  Within one
   round-trip time, the node would discover its mistake (receiving
   Packet Too Big messages from that router), but frequent repetition of
   this attack could cause lots of packets to be 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.

   A malicious party could also cause problems if it could stop a victim
   from receiving legitimate Packet Too Big messages, but in this case
   there are simpler denial-of-service attacks available.









 
RFC 1981              Path MTU Discovery for IPv6            August 1996


Acknowledgements

   We would like to acknowledge the authors of and contributors to
   [RFC-1191], from which the majority of this document was derived.  We
   would also like to acknowledge the members of the IPng working group
   for their careful review and constructive criticisms.