>>>>> On Thu, 11 Apr 2002 18:26:32 +0200 (CEST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
> Is there a middle ground where the API can be made more clear
> than using "-1" without having to replace IPV6_USE_MIN_MTU?
> We already have IPV6_option and IPV6_MULTICAST_option in some cases.
> Thus would it make sense to
> 1) declare the IPV6_USE_MIN_MTU only applies to unicast.
> 2) define a new IPV6_MULTICAST_USE_MIN_MTU whose default would be "true".
This is essentially the same idea of the original proposal...the
problem of this approach is that programmers would wonder "why
does IPV6_USE_MIN_MTU not contain "UNICAST" but the use of it is
limited to unicast?". I don't think this makes the API "more clear".
Either way we'll need to describe the background and its limitation
clearly, and if so, I'd prefer to keep the number of options.
Actually I can make a compromise with either approach *if we can make
a quick consensus*. To make the approach I proposed clearer, I've
attached concrete text for the revised version of IPV6_USE_MIN_MTU
according to my proposal. If we can live with this (though you may
prefer the other one), please let us go.
Thanks,
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,
x == -1: use kernel default. That is, perform path MTU discovery
for unicast, and disable it for multicast.
x == 0: always perform path MTU discovery.
x >= 1: always disable path MTU discovery and send packets at
the minimum MTU.
(values less than -1 are invalid.)
For 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));
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]
--------------------------------------------------------------------
