On 11/13/2012 12:27 AM, Mark Andrews wrote: > In message <50a111fb.2060...@bfk.de>, Hannes Frederic Sowa writes: >> On 11/07/2012 02:30 AM, Mark Andrews wrote: >>> Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? >>> Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? >> >> As I have not read otherwise I would treat IPV6_USE_MIN_MTU as >> transport-agnostic. > > The problem is that there are at least 2 OS's with TCP layers that > do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to > send. I would have thought that this would have been obvious to do. > > Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used > when calculating the TCP segment size?
I am in favor of deprecating this option on TCP sockets. I personally dislike this option even on datagram sockets. The tri-state value has to be checked for every packet on the output path to distinguish between multicast and unicast frames (not connected sockets essentially have two different MTUs). As such, this option could not just clamp the fragment size in the internal socket structure as the current linux(IPV6_MTU) interface does. I totally can understand Apple not including this setting in the TCP fragment size calculations, especially if this feature was added at a later time. Otherwise, I would also expect that the maximum segment size is set to 1280-40-20(-8 if atomic fragments should be produced ;) ). So, perhaps a note about the maximum segment size calculation should be added to the relevant section, too. >> The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see >> RFC3542 11.2). > > Which is short sighted. There is no reason not to apply it to all > transports as all transports have to handle PTB and this is just > a locally generated PTB. Isn't IPV6_DONTFRAG the default on TCP sockets? > And while we are talking about RFC3542 how to we get POSIX updated to > include the advanced half of the API as it is a pain in the butt for > application developers. The best place to start here would be the austin group bug tracker at <http://austingroupbugs.net>. Perhaps one could trigger the addition of the RFC5014 source selection APIs into POSIX, too. Greetings, Hannes -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
