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.
The most critical case from what we see in IPv4 is the
case of applications sending large UDP MTU (4500 bytes or the like)
that are getting fragmented at the source into 1500 byte fragments,
and then hit some PPPoE/L2TP/GRE/MPLS-VPN/etc.. links (in practice these
are hundreds of links) and you have the issue of either re-fragmentation
(v4 only) or implosion of ICMP messages. And then add the pathetic case of
the broken network with stupid access control policies, and the ICMP messages
may not make it back at all and the application breaks completely in some
subtrees of it's delivery tree, with routers continuously sending rate-limited
ICMP messages, and receivers not getting traffic.
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):
11.5 Fragmentation and IPv6 multicast packets
Path MTU discovery for multicast has severe scalability limitations
and should thus be avoided. To ease porting of ipv4 applications and
reduce the risk of application developers overlooking this issue,
originating of ipv6 multicast packets must behave in the following way:
Originating ipv6 multicast packets will insert a fragmentation header
when the data is larger than the minimum IPv6 MTU [RFC-2460] or the
interface MTU - whichever is smaller. Setting of the IPV6_USE_MIN_MTU
option on the socket has no effect on originating ipv6 multicast packets.
If an application wants to originate larger ipv6 multicast fragments than
the above default behavior, it must use the IPV6_MULTICAST_MTU_DISC
socket option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_MTU_DISC, &on, sizeof(on));
By default, this option is disabled. Enabling it will allow for the
application to originate packets as large as the interface MTU without
insertion of fragment headers (fragment headers will still be inserted
when the packet is larger than the interface MTU - unless the IPV6_DONTFRAG
option has been set of course).
The IPV6_DONTFRAG and IPV6_RECVPATHMTU options apply to ipv6 multicast
packets as they apply to ipv6 unicast packets.
Thanks
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]
--------------------------------------------------------------------
