On 08/16/10 11:38 AM, James Carlson wrote:
Erik Nordmark wrote:
Perhaps I didn't see it, but which (if either) MTU corresponds
to what may be publically seen? Or does it matter (if IP
fragmenting hides the distinction)?
IP fragmentation hides the distinction.
It is the unicast MTU that is reported using the various interfaces that
report MTU (dladm, ifconfig, routing sockets).
If you're sending multicast, I'd think you'd want to avoid the
complications involved with either fragmentation or (yikes!) MTU discovery.
There are other ways to avoid fragmentation. The IP_DONTFRAG and
IPV6_DONTFRAG socket options can be used to disable fragmentation
resulting in some error (EMSGSIZE I think) if the packet is too large.
If the application writer doesn't just force the issue off onto the user
(by requiring tuning) or always using 576 or 1280 minima, how can his IP
multicast-using application discover the correct MTU?
The only standard way to determine the (Path) MTU for a given
destination I know of this is the IPV6_PATHMTU socket option specified
in section 11.4 of RFC 3542.
But I have no idea how widely implemented this is, and whether it is
usable for IPv4 in different implementations.
Erik
I didn't think it was too uncommon to rely on SIOCGIFMTU to determine
how large a multicast packet one could send to directly-attached peers.
E.g.:
http://fxr.googlebit.com/source/usr.sbin/route6d/route6d.c?v=NETBSD-CURRENT#L788
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
