As some of you have already noticed, I submitted a new version of the
advanced API (rfc2292bis) draft.
The only change (other than minor wording nits) is as follows:
- Revised the "minimum MTU" section so that path MTU discovery would
be disabled for multicast by default. A new (default) value "-1" as
an argument was introduced accordingly.
(from Change History section)
To be more accurate, I've attached the whole section at the end of
this message.
I believe the change was based on the consensus on the list and we
can proceed to the next step with this version, but if you see any
problems please let me know.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. I've also implemented the change in the latest snapshot of our
implementation.
11.1. Sending with the Minimum MTU
Unicast applications should usually let the kernel 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 by default. Applications
sending multicast traffic should explicitly enable path MTU discovery
only when they understand that the benefit of possibly larger MTU
usage outweights the possible impact of MTU discovery for active
sources across the delivery tree(s). This default behavior is based
on today's available MTU path discovery mechanism and may change in
the future once better scalable mechanisms are sufficiently
ubiquitously available.
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
draft-ietf-ipngwg-rfc2292bis-07.txt [Page 45]
INTERNET-DRAFT Advanced Sockets API for IPv6 Apr. 19, 2002
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 therefore 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]
--------------------------------------------------------------------
