> 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.
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.
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?
Do you have an example of an application which might need such a feature?
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
