Subject: IPV6_DONTFRAG - stack behavior when packet is too big to send

From: Kristine Adamson <[email-masked]>
Date: Mon, 10 Apr 2006 11:29:34 -0600

Hello

I have a question about a stack's behavior when the IPV6_DONTFRAG socket 
option has been set for a UDP or RAW socket, and a packet is too large to 
be sent out from the stack.  RFC 3542 (Advanced Sockets Application 
Program Interface (API) for IPv6) seems to state the following about what 
the stack should do in this case:

   "When the data size is larger than the MTU of the outgoing interface,
   the packet will be discarded.  Applications can know the result by
   enabling the IPV6_RECVPATHMTU option described below and receiving
   the corresponding ancillary data items.  An additional error EMSGSIZE
   may also be returned in some implementations.  Note, however, that
   some other implementations might not be able to return this
   additional error when sending a message."

Is the stack also supposed to create an ICMPv6 Packet Too Big message to 
send up to the application?  In a multiprocessing environment, don't 
applications like Ping and Traceroute need more information that what is 
in the ip6_mtuinfo structure in order to determine if the IPV6_PATHMTU 
information was sent as a response to one of their outbound packets or 
not? 

Thanks!

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:[email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 11 Apr 2006 11:22:48 +0900

>>>>> On Mon, 10 Apr 2006 11:29:34 -0600, 
>>>>> Kristine Adamson <[email-masked]> said:

> send up to the application?

Not at least when I wrote the above text.  Our (BSD's) implementation
does not send the local ICMPv6 error message up to the application,
for that matter.

> In a multiprocessing environment, don't 

That might be a useful feature, but I personally suspect how effective
it is in practice.  First, I think the use of IPV6_DONTFRAG (+
IPV6_PATHMTU) is very rare, especially the case where multiple
processes enable this option and send large packets to the same
destination.  Secondly, since the application enabling this option is
generally expected to keep track of the transmission history in some
way, the application would be able to use the information returned via
IPV6_PATHMTU appropriately, whether or not it was caused by itself.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]