Subject: Re: source specific multicast?
To: None <email@example.com>
From: Hitoshi Asaeda <firstname.lastname@example.org>
Date: 10/04/2007 13:41:40
> do we have the necessary kernel and userland
> support for (IPv6) source specific multicast?
SSM requires "kernel implementation (by IGMPv3(IPv4) and MLDv2(IPv6))"
and "userland implementation (by MSF APIs (RFC3678))".
The latest KAME includes the kernel implementation. I think
mcast-tools would be a good examle to know how the (Basic) MSF APIs
can be used.
From here, my personal opinion.
IGMPv3/MLDv2 have very complex concepts; they include two filter-mode
operations named INCLUDE and EXCLUDE operations, while SSM only
requires INCLUDE operation. KAME's IGMPv3/MLDv2 implementations needed
strict conformance to these RFCs (3376 and 3810).
But unfortunately, state transition between INCLUDE mode and EXCLUDE
mode requires the fairly complex procedure. In addition, MSF APIs
specifies the Basic APIs and Advanced APIs, while the Advanced APIs
also requires the additional components to the kernel implementation.
Precisely because KAME completely implemented these functions, it
includes complexities and some part of codes are poorly thought out in
According to these points, IMO, implementing Lightweight-IGMPv3/MLDv2
(*1) would be favorable. LW-IGMPv3/MLDv2 would simplify the original
IGMPv3 and MLDv2 and focus on SSM (only with INCLUDE mode). These
protocols are now proposed in the IETF MBONED WG. Since these
protocols eliminate (1) an EXCLUDE mode operation and (2) MSF Advanced
APIs, the code should become very simple. We believe there is no
disadvantage in the functional elimination in practice.
I've finished LW-IGMPv3 kernel implementation for NetBSD-current. It
is now checked by itojun. (Thanks itojun!) Sooner or later, we will
open it to public. Regarding LW-MLDv2, I hope I can finish before the
next IETF (beg. Dec.).