IPv6用経路MTU探索（TCP層の作用）

   The TCP layer must track the PMTU for the path(s) in use by a
   connection; it should not send segments that would result in packets
   larger than the PMTU.  A simple implementation could ask the IP layer
   for this value each time it created a new segment, but this could be
   inefficient.  Moreover, TCP implementations that follow the "slow-
   start" congestion-avoidance algorithm [CONG] typically calculate and
   cache several other values derived from the PMTU.  It may be simpler
   to receive asynchronous notification when the PMTU changes, so that
   these variables may be updated.

   A TCP implementation must also store the MSS value received from its
   peer, and must not send any segment larger than this MSS, regardless
   of the PMTU.  In 4.xBSD-derived implementations, this may require
   adding an additional field to the TCP state record.

   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.  See [IPv6-SPEC] sections
   "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for
   information on selecting a value for the TCP MSS option.

   When a Packet Too Big message is received, it implies that a packet
   was dropped by the node that sent the ICMP message.  It is sufficient
   to treat this as any other dropped segment, and wait until the
   retransmission timer expires to cause retransmission of the segment.
   If the Path MTU Discovery process requires several steps to find the
   PMTU of the full path, this could delay the connection by many
   round-trip times.

   Alternatively, the retransmission could be done in immediate response
   to a notification that the Path MTU has changed, but only for the
   specific connection specified by the Packet Too Big message.  The
   packet size used in the retransmission should be no larger than the
   new PMTU.

      Note: A packetization layer must not retransmit in response to
      every Packet Too Big message, since a burst of several oversized
      segments will give rise to several such messages and hence several
      retransmissions of the same data.  If the new estimated PMTU is
      still wrong, the process repeats, and there is an exponential
      growth in the number of superfluous segments sent.

      This means that the TCP layer must be able to recognize when a
      Packet Too Big notification actually decreases the PMTU that it
      has already used to send a packet on the given connection, and
      should ignore any other notifications.

   Many TCP implementations incorporate "congestion avoidance" and
   "slow-start" algorithms to improve performance [CONG].  Unlike a
   retransmission caused by a TCP retransmission timeout, a
   retransmission caused by a Packet Too Big message should not change
   the congestion window.  It should, however, trigger the slow-start
   mechanism (i.e., only one segment should be retransmitted until
   acknowledgements begin to arrive again).

   TCP performance can be reduced if the sender's maximum window size is
   not an exact multiple of the segment size in use (this is not the
   congestion window size, which is always a multiple of the segment
   size).  In many systems (such as those derived from 4.2BSD), the
   segment size is often set to 1024 octets, and the maximum window size
   (the "send space") is usually a multiple of 1024 octets, so the
   proper relationship holds by default.  If Path MTU Discovery is used,
   however, the segment size may not be a submultiple of the send space,
   and it may change during a connection; this means that the TCP layer
   may need to change the transmission window size when Path MTU
   Discovery changes the PMTU value.  The maximum window size should be
   set to the greatest multiple of the segment size that is less than or
   equal to the sender's buffer space size.