>>>>> On Tue, 16 Apr 2002 23:06:20 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> Why the x >=1 as opposed to x == 1? To be compatible with existing
>> applications?
>> The reason I'm asking is because it looks a bit odd to disallow less than -1
>> when greater than 1 is allowed.
> I was afraid that there may be an existing implementation which tries
> to set a positive but !=1 value to set the IPV6_USE_MIN_MTU option.
> But, this is probably an imaginary fear...actually all implementations
> that I know of use the value 1 for this purpose. So, I basically
> agree that it is more natural to restrict the positive value (to 1) as
> well.
I've attached a revised version of the proposed text according to
discussions after the proposal, including very recent results.
I'll soon submit a new I-D with this change, but if you see something
missing in the attached text, please let me know.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
11.1. Sending with the Minimum MTU
Unicast applications should usually let the kernel to perform path
MTU discovery, as long as the kernel support it, and should not care
about the path MTU. Some applications, however, might not want to
incur the overhead of path MTU discovery, especially if the
applications only send a single datagram to a destination. A
potential example is a DNS server.
Also, path MTU discovery for multicast has severe scalability
limitations and should thus be avoided.
This specification defines a mechanism to avoid path MTU discovery by
sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger
than the minimum MTU and this feature has been enabled the IP layer
will fragment to the minimum MTU. To control the policy about path
MTU discovery, applications can use the IPV6_USE_MIN_MTU socket
option.
As described above, the default policy should depend on whether the
destination is unicast or multicast. For unicast destinations path
MTU discovery should be performed by default. For multicast
destinations path MTU discovery should be disabled by default. This
option thus takes the following three types of integer arguments:
-1: Perform path MTU discovery for unicast destinations but do
not perform it for multicast destinations. Packets to multicast
destinations are therefor sent with the minimum MTU.
0: always perform path MTU discovery.
1: always disable path MTU discovery and send packets at the
minimum MTU.
The default value of this option is -1. Values other than -1, 0, and
1 are invalid, and an error EINVAL will be returned for those values.
As an example, if a unicast application intentionally wants to
disable path MTU discovery, it will add the following lines:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
Note that this API intentionally excludes the case where the
application wants to perform path MTU discovery for multicast but to
disable it for unicast. This is because such usage is not feasible
considering a scale of performance issues around whether to do path
MTU discovery or not. When path MTU discovery makes sense to a
destination but not to a different destination, regardless of whether
the destination is unicast or multicast, applications either need to
toggle the option between sending such packets on the same socket, or
use different sockets for the two classes of destinations.
This option can also be sent as ancillary data. In the cmsghdr
structure containing this ancillary data, the cmsg_level member will
be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and
the first byte of cmsg_data[] will be the first byte of the integer.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
