Section 14. Maximum Packet Size

A DCCP implementation MUST maintain the maximum packet size (MPS)
   allowed for each active DCCP session.  The MPS is influenced by the
   maximum packet size allowed by the current congestion control
   mechanism (CCMPS), the maximum packet size supported by the path's
   links (PMTU, the Path Maximum Transmission Unit) [RFC1191], and the
   lengths of the IP and DCCP headers.
   A DCCP application interface SHOULD let the application discover
   DCCP's current MPS.  Generally, the DCCP implementation will refuse
   to send any packet bigger than the MPS, returning an appropriate
   error to the application.  A DCCP interface MAY allow applications to
   request fragmentation for packets larger than PMTU, but not larger
   than CCMPS.  (Packets larger than CCMPS MUST be rejected in any
   case.)  Fragmentation SHOULD NOT be the default, since it decreases
   robustness: an entire packet is discarded if even one of its
   fragments is lost.  Applications can usually get better error
   tolerance by producing packets smaller than the PMTU.
   The MPS reported to the application SHOULD be influenced by the size
   expected to be required for DCCP headers and options.  If the
   application provides data that, when combined with the options the
   DCCP implementation would like to include, would exceed the MPS, the
   implementation should either send the options on a separate packet
   (such as a DCCP-Ack) or lower the MPS, drop the data, and return an
   appropriate error to the application.
14.1.  Measuring PMTU
   Each DCCP endpoint MUST keep track of the current PMTU for each
   connection, except that this is not required for IPv4 connections
   whose applications have requested fragmentation.  The PMTU SHOULD be
   initialized from the interface MTU that will be used to send packets.
   The MPS will be initialized with the minimum of the PMTU and the
   CCMPS, if any.
   Classical PMTU discovery uses unfragmentable packets.  In IPv4, these
   packets have the IP Don't Fragment (DF) bit set; in IPv6, all packets
   are unfragmentable once emitted by an end host.  As specified in
   [RFC1191], when a router receives a packet with DF set that is larger
   than the next link's MTU, it sends an ICMP Destination Unreachable
   message back to the source whose Code indicates that an
   unfragmentable packet was too large to forward (a "Datagram Too Big"
   message).  When a DCCP implementation receives a Datagram Too Big
   message, it decreases its PMTU to the Next-Hop MTU value given in the
   ICMP message.  If the MTU given in the message is zero, the sender
   chooses a value for PMTU using the algorithm described in [RFC1191],
   Section 7.  If the MTU given in the message is greater than the
   current PMTU, the Datagram Too Big message is ignored, as described
   in [RFC1191].  (We are aware that this may cause problems for DCCP
   endpoints behind certain firewalls.)
   A DCCP implementation may allow the application occasionally to
   request that PMTU discovery be performed again.  This will reset the
   PMTU to the outgoing interface's MTU.  Such requests SHOULD be rate
   limited, to one per two seconds, for example.
   A DCCP sender MAY treat the reception of an ICMP Datagram Too Big
   message as an indication that the packet being reported was not lost
   due to congestion, and so for the purposes of congestion control it
   MAY ignore the DCCP receiver's indication that this packet did not
   arrive.  However, if this is done, then the DCCP sender MUST check
   the ECN bits of the IP header echoed in the ICMP message and only
   perform this optimization if these ECN bits indicate that the packet
   did not experience congestion prior to reaching the router whose link
   MTU it exceeded.
   A DCCP implementation SHOULD ensure, as far as possible, that ICMP
   Datagram Too Big messages were actually generated by routers, so that
   attackers cannot drive the PMTU down to a falsely small value.  The
   simplest way to do this is to verify that the Sequence Number on the
   ICMP error's encapsulated header corresponds to a Sequence Number
   that the implementation recently sent.  (According to current
   specifications, routers should return the full DCCP header and
   payload up to a maximum of 576 bytes [RFC1812] or the minimum IPv6
   MTU [RFC2463], although they are not required to return more than 64
   bits [RFC792].  Any amount greater than 128 bits will include the
   Sequence Number.)  ICMP Datagram Too Big messages with incorrect or
   missing Sequence Numbers may be ignored, or the DCCP implementation
   may lower the PMTU only temporarily in response.  If more than three
   odd Datagram Too Big messages are received and the other DCCP
   endpoint reports more than three lost packets, however, the DCCP
   implementation SHOULD assume the presence of a confused router and
   either obey the ICMP messages' PMTU or (on IPv4 networks) switch to
   allowing fragmentation.
   DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP
   endpoint begins by sending small packets with DF set and then
   gradually increases the packet size until a packet is lost.  This
   mechanism does not require any ICMP error processing.  DCCP-Sync
   packets are the best choice for upward probing, since DCCP-Sync
   probes do not risk application data loss.  The DCCP implementation
   inserts arbitrary data into the DCCP-Sync application area, padding
   the packet to the right length.  Since every valid DCCP-Sync
   generates an immediate DCCP-SyncAck in response, the endpoint will
   have a pretty good idea of when a probe is lost.
14.2.  Sender Behavior
   A DCCP sender SHOULD send every packet as unfragmentable, as
   described above, with the following exceptions.
   o  On IPv4 connections whose applications have requested
      fragmentation, the sender SHOULD send packets with the DF bit not
      set.
   o  On IPv6 connections whose applications have requested
      fragmentation, the sender SHOULD use fragmentation extension
      headers to fragment packets larger than PMTU into suitably-sized
      chunks.  (Those chunks are, of course, unfragmentable.)
   o  It is undesirable for PMTU discovery to occur on the initial
      connection setup handshake, as the connection setup process may
      not be representative of packet sizes used during the connection,
      and performing MTU discovery on the initial handshake might
      unnecessarily delay connection establishment.  Thus, DCCP-Request
      and DCCP-Response packets SHOULD be sent as fragmentable.  In
      addition, DCCP-Reset packets SHOULD be sent as fragmentable,
      although typically these would be small enough to not be a
      problem.  For IPv4 connections, these packets SHOULD be sent with
      the DF bit not set; for IPv6 connections, they SHOULD be
      preemptively fragmented to a size not larger than the relevant
      interface MTU.
   If the DCCP implementation has decreased the PMTU, the sending
   application has not requested fragmentation, and the sending
   application attempts to send a packet larger than the new MPS, the
   API MUST refuse to send the packet and return an appropriate error to
   the application.  The application should then use the API to query
   the new value of MPS.  The kernel might have some packets buffered
   for transmission that are smaller than the old MPS but larger than
   the new MPS.  It MAY send these packets as fragmentable, or it MAY
   discard these packets; it MUST NOT send them as unfragmentable.