IP_MTU_DISCOVER(2const)                                IP_MTU_DISCOVER(2const)

NAME
       IP_MTU_DISCOVER - path maximum transfer unit size discovery

LIBRARY
       Standard C library (libc, -lc)

SYNOPSIS
       #include <netinet/in.h>  /* Definition of IP* constants */
       #include <sys/socket.h>

       int setsockopt(int sockfd, IPPROTO_IP, IP_MTU_DISCOVER,
                      const int *val, sizeof(int));
       int getsockopt(int sockfd, IPPROTO_IP, IP_MTU_DISCOVER,
                      int *val, sizeof(int));

DESCRIPTION
       Set or receive the Path MTU Discovery setting for a socket.

       When enabled, Linux will perform Path MTU Discovery as defined in
       RFC 1191 on SOCK_STREAM sockets.

       For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the don't-fragment
       flag to be set on all outgoing packets.  It is the user's
       responsibility to packetize the data in MTU-sized chunks and to do the
       retransmits if necessary.  The kernel will reject (with EMSGSIZE)
       datagrams that are bigger than the known path MTU.  IP_PMTUDISC_WANT
       will fragment a datagram if needed according to the path MTU, or will
       set the don't-fragment flag otherwise.

       The system-wide default can be toggled between IP_PMTUDISC_WANT and
       IP_PMTUDISC_DONT by writing (respectively, zero and nonzero values) to
       the /proc/sys/net/ipv4/ip_no_pmtu_disc file.

       Path MTU discovery value   Meaning
       IP_PMTUDISC_WANT           Use per-route settings.
       IP_PMTUDISC_DONT           Never do Path MTU Discovery.
       IP_PMTUDISC_DO             Always do Path MTU Discovery.
       IP_PMTUDISC_PROBE          Set DF but ignore Path MTU.

       When PMTU discovery is enabled, the kernel automatically keeps track of
       the path MTU per destination host.  When it is connected to a specific
       peer with connect(2), the currently known path MTU can be retrieved
       conveniently using the IP_MTU(2const) socket option (e.g., after an
       EMSGSIZE error occurred).  The path MTU may change over time.  For
       connectionless sockets with many destinations, the new MTU for a given
       destination can also be accessed using the error queue (see
       IP_RECVERR(2const)).  A new error will be queued for every incoming MTU
       update.

       While MTU discovery is in progress, initial packets from datagram
       sockets may be dropped.  Applications using UDP should be aware of this
       and not take it into account for their packet retransmit strategy.

       To bootstrap the path MTU discovery process on unconnected sockets, it
       is possible to start with a big datagram size (headers up to 64
       kilobytes long) and let it shrink by updates of the path MTU.

       To get an initial estimate of the path MTU, connect a datagram socket
       to the destination address using connect(2) and retrieve the MTU by
       calling getsockopt(2) with the IP_MTU(2const) option.

       It is possible to implement RFC 4821 MTU probing with SOCK_DGRAM or
       SOCK_RAW sockets by setting a value of IP_PMTUDISC_PROBE.  This is also
       particularly useful for diagnostic tools such as tracepath(8) that wish
       to deliberately send probe packets larger than the observed Path MTU.

ERRORS
       See IPPROTO_IP(2const).  See setsockopt(2).  See ip(7).

STANDARDS
       Linux.

HISTORY
       Linux 2.2.

       IP_PMTUDISC_PROBE
              Linux 2.6.22.

SEE ALSO
       IPPROTO_IP(2const), setsockopt(2), ip(7)

Linux man-pages 6.17              2025-11-25           IP_MTU_DISCOVER(2const)