>>>>> On Fri, 17 Nov 2000 16:21:19 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> I think this type of option can be useful, but I still think the
>> IPV6_USEMTU option (which allows an application to specify the path
>> MTU for an outgoing packet) is useful as well. And, if we take this
>> approach, prohibiting fragment can be implemented as a special case of
>> the option (i.e, setting a very large value as the MTU). What do you
>> think of this?
> If we want an IPV6_USEMTU option I think that needs to be separate from
> prohibiting fragmentation, since I think the overloading you propose would
> be confusing.
Hmm, okay, I agree.
> If the path MTU is 2000 bytes and the interface MTU is 8000 bytes
> I would expect that an IPV6_USEMTU value between 2000 and 8000 would
> transmit an unfragmented packet. I assume your proposal is that when the
> IPv6_USEMTU value is set to a number larger than 8000 this would cause
> the packet to be dropped (and an IPV6_PATHMTU sent up as ancillary data
> if the socket had IPV6_RECVPATHMTU enabled). Thus setting IPV6_USEMTU
> to 2^^32-1 would be the same as disabling fragmentation.
Yes, that was my intention, but I now agree with a separate socket
option to disable fragmentation.
> 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)
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).
> Do you have an example of an application which might need such a feature?
Yes, please see the attached e-mail. As described in the message, NFS
might not be a good example (due to the actual implementation issue).
However, NetBSD's IPv6 NFS implementation has this kind of problem,
and currently does not work if the path MTU is smaller than the MTU of
the outgoing interface. I can easily imagine a same kind of prroblem
can arise for "pure" user space applications, and, in fact, DHCPv6
server could be a practical example (as I said in the attached
e-mail).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
>>>>> On Tue, 14 Nov 2000 09:42:19 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
> I'm now considering UDP applications that are sensitive to path MTU
> (toward the destinations). I recalled a discussion about a new socket
> option "IPV6_USEMTU", which allowed an application to specify an
> appropriate path MTU for packets sent from the application. I checked
> the archive of this list in April 2000, and, to my suprise, the
> discussion suddenly disappeared without any consensus.
> => today only IPV6_USE_MIN_MTU seems to be defined, implemented and
> used (for instance by BIND and racoon, the KAME IKE daemon).
> I don't know if IPV6_USEMTU as you define is very useful but the
> getsockopt() counterpart (which gives the actual path MTU) *is* useful.
> Perhaps the getsockopt() with a standard way to disable fragmentation
> is enough (it should be enough for a traceroute_pmtu6)?
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.
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]
--------------------------------------------------------------------
