>>>>> On Fri, 5 Apr 2002 10:26:05 -0800,
>>>>> Toerless Eckert <[EMAIL PROTECTED]> said:
> I would like to propose another section to rfc2292bis for the issue
> of MTU path discovery with ipv6 multicast. The issue with the current
> rfc2292bis draft is that path discovery is enabled by default on
> ipv6 sockets and with ipv6 multicast this is something that applications
> should shy away from much more than unicast fragmentation because of the
> implosion of IGMP messages sent back to the source.
^^^^should be ICMP
(snip)
> For this reason, i would like to propose the following, and i am not
> sure wether or not this could entirely be put into rfc2292bis or if
> this would also be considered to be an architectural issue (i hope it
> can really be claimed to be a socket behavior only issue and thus
> rfc2292bis):
I see your point. However, I'm not sure if we really need a new
option to deal with this issue. An application can in fact avoid ICMP
implosion by setting IPV6_USE_MIN_MTU. This only requires 4 (or a bit
more) additional lines like:
{
int on = 1;
if (setsockopt(sock, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)))
/* error handling */;
}
Is it really a big deal to let programmers omit the additional lines,
comparing to the complexity of adding a new socket option? My
personal feeling is that it is enough to add some note which suggests
setting IPV6_USE_MIN_MTU for sockets used to send multicast packets.
Secondly, the proposed option "IPV6_MULTICAST_MTU_DISC" seems to me a
bit ad-hoc. If we wanted to go with this path, I'd rather generalize
the MTU-related option like as follows:
- add a new socket option, say, "IPV6_PMTU_DISC", which takes an
integer as an argument
- the semantics of the argument is:
+ 0: let the kernel make a decision whether to perform path MTU
discovery. the recommended way to make the decision is:
fragment packets at the minimum MTU if the destination is a
multicast address. otherwise, perform path MTU discovery.
+ 1: force the kernel to perform path MTU discovery
+ 2: specify the kernel to fragment packets at the minimum MTU
(equivalent to IPV6_USE_MIN_MTU)
+ 3: specify the kernel not to fragment packets
(equivalent to IPV6_DONTFRAG)
- this option can also be used as an ancillary data item for
per-packet control.
- IPV6_USE_MIN_MTU and IPV6_DONTFRAG will be deprecated by the new
IPV6_PMTU_DISC option.
(There should have been a similar proposal before, but I don't recall
the result of the discussion.)
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]
--------------------------------------------------------------------
