>>>>> On Sat, 18 Nov 2000 18:13:40 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
>> But when using IPV6_USEMTU as you propose would the MTU be for all
>> destination addresses on the socket? Or would IPV6_USEMTU carry
>> an address in addition to an mtu?
> Well, sorry, the wording was incorrect in the original message. I
> intended a new ancillary data item "IPV6_USEMTU" (not a socket option)
> => I am in the principle strongly against something which is available
> only as an ancillary data and not a socket option.
A setsockopt equivalent of this ancillary data item is also available
(especially for connected sockets). However, my main concern here is
about non-connected UDP server applications, where ancillary data
would be more suitable than a sticky socket option.
> for outgoing UDP or raw IPv6 packets, because I imagined an
> application which opens a singe, non-connected socket for multiple
> destinations. The IPV6_USEMTU item, of course, would affect the
> corresponding outgoing packet only. This also means that the actual
> data for IPV6_USEMTU contains the path MTU only (which may be a 32bit
> integer).
> => with IPV6_USEMTU IPV6_USE_MIN_MTU is no more useful (it is IPV6_USEMTU
> with 1280).
Correct. So, IPV6_USEMTU would obsolete IPV6_USE_MIN_MTU.
> My main concern is about UDP applications that can't divide outgoing
> data into multiple packets but do not want to fragment the packet in a
> (much) smaller size than the path MTU. Possible examples would be NFS
> and DHCP. I admit that NFS may not be a good example, because in UNIX
> systems, NFS is typically implemented in the kernel.
> => I still can't see if IPV6_USEMTU is very useful. Why don't rely
> on the standard fragmentation when paths are stable and on IPV6_USE_MIN_MTU
> when they are unstable and this is very important to avoid the lost
> of first packets (the price of path MTU discovery). NFS is in the first
> category, the DNS and IKE in the second with perhaps off-link DHCP.
Because we can't always rely on the kernel performing path MTU
discovery when there's no connected PCB. The latest version of NetBSD
is an example of not performing path MTU discovery without a
corresponding connected PCB (for a security reason)[*]. I agree that
we don't need the IPV6_USEMTU ancillary data (and socket option) if
all kernel implementations surely perform path MTU discovery
regardless of existence of a connected PCB.
([*]there are some other conditions, but they are not really related
to this discussion, so I just omitted them.)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
