On Sat, Apr 06, 2002 at 04:49:20PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> 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.
Well, i've just seen bad and worse ip multicast applications over the
last 10 years, programmers have been ignorant about the issues at hand
and people who deploy the applications have been ignorant about the
network issues they cause. So my point in face of all this is those
two recommendations in my original mail:
- Change the default behavior (1280 max MTU) for ip multicast
packets so all those lazy programmers and users get the desired
default behavior. Don't trust them to do/program the right thing by
default.
- Ignore the setting of IPV6_USE_MIN_MTU. Again, this is for reasons of
avoiding that programmers who don't really think about multicast
but use it will get the wrong default behavior. It would be completely
confusing to have the default behavior for sending ip multicast packets
to be 1280, but then if somebody explicitly set's IPV6_USE_MIN_MTU to
OFF, we would change - that is, why i am very much persuaded, that
this option should only apply for unicast.
> 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:
Yes, the proposed option was ad-hoc and i am happy with trying to make
it more generic, but again:
- The main key to all the API issues is the fact that we should have
two different defaults for unicast and multicast: Path MTU discovery
is cool and wonderfull for unicast, it is bad and silly for multicast
(especially for non-ssm style multicast where you may have groups
with thousands of hosts starting to send few packets amongst themselves
and routers really don't want to keep track of them individually).
- Because of the different default behaviors that we want for unicast
and multicast, a more generic option should always differentiate
wether it is applied to unicast and/or multicast !
> - 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.
So, logically i want a second argument: wether or not this option should
apply to unicast and/or multicast. Now we can still make this all one
integer by using a simple bitmask:
#define PMTU_UNICAST 1
#define PMTU_MULTICAST 2
#define PMTU_ALLPAKETS 3
#define PMTU_DEFAULT 0 /* default behavior: ucast:disc, mcast:min */
#define PMTU_MTUDISC 4
#define PMTU_MINMTU 8
#define PMTU_DONTFRAG 12
(eg: setsockopt(s, IPPROTO_IPV6, IPV6_PMTU_DISC,
PMTU_ALLPAKETS | PMTU_DONTFRAG))
or use bitfield definitions if that's more conformant with policies.
And if that option would replace USE_MIN_MTU and DONTFRAG, then i would
like that very much !
Cheers
Toerless
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
