This is what I've edited together so far.
Note that the IPV6_PATHMTU option is used both as ancillary data (when
IPV6_RECVPATHMTU is enabled) and with getsockopt to retrieve the 
current path MTU value for a destination.

Comments?
   Erik


11.1.  Sending with the Minimum MTU

   Some applications might not want to incur the overhead of path MTU
   discovery, especially if the applications only send a single datagram
   to a destination.  A potential example is a DNS server.

   This specification defines a mechanism to avoid path MTU discovery by
   sending at the minimum IPv6 MTU [RFC-2460].  If the packet is larger
   than the minimum MTU and this feature has been enabled the IP layer
   will fragment to the minimum MTU.  This can be enabled using the
   IPV6_USE_MIN_MTU socket option.

       int  on = 1;
       setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));

   By default, this socket option is disabled.  Setting the value to 0
   also disables the option.  This option can also be sent as ancillary
   data.



11.2.  Sending without fragmentation

   In order to provide for easy porting of existing UDP and raw socket
   applications IPv6 implementations will, when originating packets,
   automatically insert a fragment header in the packet if the packet is
   too big for the path MTU.

   Some applications might not want this behavior.  An example is
   traceroute which might want to discover the actual path MTU.

   This specification defines a mechanism to turn off the automatic
   inserting of a fragment header for UDP and raw sockets.  This can be
   enabled using the IPV6_DONTFRAG socket option.

       int on = 1;
       setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on));

   By default, this socket option is disabled.  Setting the value to 0
   also disables the option i.e. reverts to the default behavior of
   automatic inserting.  This option can also be sent as ancillary data.




11.3.  Path MTU Discovery and UDP

   UDP and raw socket applications need to be able to  determine the
   "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to
   a given destination so that those applications can participate in
   path MTU discovery.  This lets those applications send smaller
   datagrams to the destination, avoiding fragmentation.

   This is accomplished using a new ancillary data item (IPV6_PATHMTU)
   which is delivered to recvmsg() without any actual data.  The
   application enable the receipt of IPV6_PATHMTU ancillary data items
   by enabing IPV6_RECVPATHMTU.

       int  on = 1;
       setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));

   By default, this socket option is disabled.  Setting the value to 0
   also disables the option.

   When the application is sending packets too big for the path MTU
   recvmsg will return zero (indicating no data) but there will be a
   cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
   indicate that cmsg_data is 4 bytes long.  CMSG_DATA will point to a
   struct ip6_ carrying the path MTU to use together with the IPv6
   destination address.

       struct ip6_mtuinfo {
         struct sockaddr_in6 ip6m_addr;    /* dst IPv6 address including scope
*/
         unsigned int        ip6m_mtu;     /* path MTU in host byte order */
       };



   XXX What about more complex paths e.g. when using a routing header?



11.4.  Determining the current path MTU

   Some applications might need to determine the current path MTU e.g.
   applications using IPV6_RECVPATHMTU might want to pick a good
   starting value.

   This specification defines a socket option to retrieve the current
   path MTU value for a given destination address.  If the IP layer does
   not have a cached path MTU value it will return the interface MTU for
   the interface that will be used when sending to the specified IPv6
   address.

   This information is retrived using IPV6_PATHMTU.

       struct ip6_mtuinfo mtuinfo;
       mtuinfo.ip6m_addr = addr;    /* address */
       getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, sizeof(&mtuinfo));



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to