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.
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).
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.
Thanks
[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]
--------------------------------------------------------------------
